newbie question

[HughBanton]

Hi there, I'm new here ... at least you'd think so when you see my question !!

I've been trying to investigate whether it's possible to change a MIDI note's velocity after it has started; had an idea for something I'm doing with Arduino right now. I'm certainly expecting the answer to be 'NO', and if anyone can confirm that it'll save me going any further!

However to test this I set up the attached (about as basic as you can make) so that I could send different velocities of a given MIDI note, without sending a note-off message. Not so easy from a regular keyboard.

Now with the MIDI to Voices prim I've always been under the impression, if you set NoRpt == true, then repeating a single note should always direct it to the same single voice ..

"The NoRpt input allows you to choose to reuse the same voice whenever the same note is repeatedly
played instead of repeating the note in a new voice each time (the default behaviour)".

Yet if I re-trigger the note 4 times it goes to 4 voices, no matter which way any of the switches are set.

Evidently I'm misunderstanding something .. help!

H

vel_test.fsm

(1.2 KiB) Downloaded 381 times

[tulamide]

I can't really help with the voices part, but you already break the midi protocol earlier. MIDI is well defined. Every Note On must have a corresponding Note Off. "Changing" the velocity of a midi note that's already triggered is not possible with MIDI. So, what happens then?
Every Note on is at least one voice on its own, per MIDI protocol, because it will sound until a Note off comes in. You're actually lucky, that Flowstone seems to be clever enough to not let hanging notes happen in this case, but shutting off all voices from one Note off. Tbh, I suspect this is simply a miss working in your favor!

[HughBanton]

Ah yes, thanks, I had suspected changing velocity mid-stream would be a no-no. (Maybe in MIDI 2.0?)

I've recently devised a MIDI Arduino keyboard scanner, interesting project, where velocity is derived by timing the period between the upper and lower contacts. Got it working well. Although this is a universal method in digital pianos, for example, the snag from a player's point of view is the inevitable lag you get because nothing at all happens until after the lower contact has closed.

In a mechanical organ action (my subject!) the valve under the pipe starts to open immediately at the top of the key-stroke, not at the bottom, so I wondered about being able to set things in motion earlier, immediately after the top contact closes, and modify the velocity later. Oh, well ...

As for Flowstone voices, I think I've now figured what the manual is referring to re " .. same note is repeatedly played". It'll be the situation where a MIDI note-off has occurred, but its envelope's release is still in progress. If during this period the same note is pressed again, && if NoRpt is set to true, then FS uses the same SSE channel again rather than a new one. But it needs the envelope overlap to make this work .. not the case in my experiment.

I'm sure I used to know all this .. one of those things you just take for granted for years & years until something like this turns up!

H

[Spogg]

Interesting topic! It raises the issue of playing latency because there’s a certain time between first touching the key and the key being fully down, which of course is how you derive velocity. Fortunately this latency is so short that we don’t perceive it, even though it has to be there.

If you have an ancient organ where the keys directly control the opening of the air valve to the pipe (not via a solenoid) I can imagine that at low velocities the sound would have a slower attack. My approach to simulate that would be to use the MIDI velocity to increase the attack time at lower velocities, so a sharp strike would give a faster onset time for the pipe to speak.

Also, if you have a grandmother, I could instruct her in the art of sucking eggs.

[HughBanton]

.. instruct her in the art of sucking eggs

[HughBanton]

So (putting velocity aside for a mo) I thought I'd quickly verify my assumption about the functionality of 'No Repeat' in the MIDI to Voices module.

I've added an envelope element that simply holds any note for 3 seconds, giving you time to press the note triggers on & off. To make life easier (and to take my illegal-MIDI-keyer out of the equation ) I've added a regular keyboard MIDI_In as well.

To my surprise I can't see it doing what I thought it should do .. I fully expected that when NoRpt==true, and the same note quickly repeated, that only SSE channel 0 would ever play, but it seems to go on to the other three SSE channels regardless. This is rather odd, surely?

vel_test_with env.fsm

(1.81 KiB) Downloaded 380 times

I must be misunderstanding, wouldn't be the first time.

H

[tulamide]

I tried Hugh, I really tried. But it acts strangely.

First of all, you are right in your understanding of the definition. I repeat the quote from the component reference:
"The NoRpt input allows you to choose to reuse the same voice whenever the same note is repeatedly
played instead of repeating the note in a new voice each time (the default behaviour)."

I don't think that can be misunderstood. It simply doesn't do what's described. When you view the ID output, you can clearly see, that it's generating a new ID everytime you play the same note. Which also adds to me thinking it doesn't work. You wouldn't need a new ID for the same note played on the same voice. The same is true for ALL outputs. Wether pitch, velocity, etc, they all report 4 voices when repeatedly hitting the same note.

However, and this is the part, where DSP pros have to chip in, if I'm not completely wrong, then voices are not channels. You seem to set SSE channels equal to voices. A voice (let's call it voice_a) is a stream of data. But for the stream it doesn't make a difference if it is streamed through SSE channel 0, 1, 2 or 3. It is still voice_a, wether it's on channel 2 or 3, for example. Of course, I would assume the same as you did, which is that re-using the same voice, when we have just one channel active, should not activate a second channel.

But that's, where the pros have to say their two cents. But it's also just a sideshow. Regarding NoRpt, I'm pretty sure it doesn't work.

[HughBanton]

Thanks for the confirmation, Tulamide, it's a most unexpected lateral discovery.

It's still the same in 64_bit (as you've no doubt discovered), so I'll start a thread in 'bugs' on Discord later .. might not get spotted here.

Dealing with 'pipes' (as I do endlessly ..) it's strange that I've previously not noticed. Big pipes in particular have a sizeable release period, as their wind pressure collapses, and upon repeating a note what you really want to happen is for the virtual wind supply to 'carry on from where it left off', rather than start at zero again. Precisely what I'd assumed NoRpt would do!

H

[Spogg]

I often wondered about this no repeat function, so this topic has spurred me on to check it out and the schematic really helped clarify stuff for me.

The function does work BUT you have to make use of the FastRelease output from the Env prim so the poly system can kill the voice instantly and this has to be via the envelope’s DSP.

As the modified schematic shows, what happens is every time the same note is played the current channel (voice) is closed and a new one opened instantly, and for a single note played repeatedly the channels are swapped back and forth, so you only get one instance of the note. That saves CPU and eliminates audio cancellation/summation issues with the same oscillator sounding more than once.

I checked this out with a regular ADSR and then modified the 3 second timer so the voice could be killed by the poly system.

If the NoRpt input is True, the NoSus input is irrelevant. The NoSus input is only used if the NoRpt input is False. In this case the swapping of channels only happens when the sustain pedal is pressed.

I’ve added comments to the updated schematic.

[Spogg]

... Big pipes in particular have a sizeable release period, as their wind pressure collapses, and upon repeating a note what you really want to happen is for the virtual wind supply to 'carry on from where it left off', rather than start at zero again. Precisely what I'd assumed NoRpt would do!

I think the only way to simulate this authentically with a synthesiser is for each pipe to be running in blue. You’d need a MIDI module for each note (or use DSP to distribute the gates) and an envelope generator in blue which, for a pipe, would ramp up when gated ON and ramp down when the gate goes away. Then a new gate signal would simply restart from the current value and go back up to 1.

I’ve used a similar technique in my SIM GANGSA and GUZHENG (with suitable envelope shapes). The obvious disadvantage is that all the blue stuff is constantly using CPU but, on the other hand, the polyphony is infinite since whatever you play won’t increase the CPU load further. It would be essential to make extensive use of Mono4, so for a 5 octave key span (61 notes) you’d have 16 voices worth of CPU all the time.