Is poly processed in batches?

MegaHurtz · 3 Mar 2010

The whole synth is processed in a thread, and stacked accordingly. Since poly is the part that goes to your dsp, and the green part of the thread goes to your cpu. there may be a difference in timing between the easilly stalled cpu, and the very constant dsp. wher your cpu is less contant becouse it`s running windows and synthmaker. and you soundcard dsp is fast becouse it has to output the right frequency.

oddson · 3 Mar 2010

How are you determining the order after you split them out? Once White is split off there's no way to compare them except to use Poly2Mono then Mono2Float and the latter will be subject to the usual problem of how it's triggered.

Unless you're saying you're producing sound with each method and there is an audible difference in the event order than from the input... but then the difference is very large 😕

Without knowing more about what you're doing it's impossible to say where it's coming from.

mwvdlee · 3 Mar 2010

oddson wrote: How are you determining the order after you split them out? Once White is split off there's no way to compare them except to use Poly2Mono then Mono2Float and the latter will be subject to the usual problem of how it's triggered.

Unless you're saying you're producing sound with each method and there is an audible difference in the event order than from the input... but then the difference is very large 😕

Without knowing more about what you're doing it's impossible to say where it's coming from.

Basically I'm using green to send "End" messages to poly envelope modules of a certain note. Sometimes, when I hit the note and the "end-note" quickly after eachother, the note just keeps on playing. The idea is to mute a certain subset of notes when a specific MIDI message occurs. So the effect is very audible indeed because I hear notes playing that should be silent 🙂

When I log the MIDI, the order seems correct and I'm only getting one MIDI message at a time, so the MIDI input is correct.

The only way for it to fail then is when the green "end" messages are sent BEFORE the white poly note starts playing. The only way I can think of for that to happen is that poly is calculated in batches and the new note just happens to be started in a batch AFTER the green "end" message is sent, thus not "seeing" the "end" message.

Knowing if poly is handled in batches and, if so, how large these batches are might help me solve this issue.

Ofcourse, if one could share data between white poly's without having to "go green", that would help too 😉

oddson · 3 Mar 2010

I'm not really in an area of expertise but I'd say the amount of time would be equal to the buffer size setting on your sound card.

I think what you need is to use the gate output from the MIDI2Poly to keep it in poly.

MichaelBenjamin · 3 Mar 2010

if these are 2 separate white streams, you can exchange data by going to blue and then back to white. since your green trigger is mono anyways you could do the same with combining the gate and putting it back to white. with some effort you can do this for a max 4 poly. if this is what you mean? btw its no wonder your data gets messed up since you are using green, which has such a shitty timing that its unusable to be reinserted in any schematic not modelling the behavior of a spastic clown inside an insolvent circus.

mwvdlee · 3 Mar 2010

MichaelBenjamin wrote: if these are 2 separate white streams, you can exchange data by going to blue and then back to white. since your green trigger is mono anyways you could do the same with combining the gate and putting it back to white. with some effort you can do this for a max 4 poly. if this is what you mean? btw its no wonder your data gets messed up since you are using green, which has such a shitty timing that its unusable to be reinserted in any schematic not modelling the behavior of a spastic clown inside an insolvent circus.

Well, it's not quite 2 separate white streams comming from separate MIDI inputs. I'm trying to share data amongst multiple poly's from a single MIDI-to-voice-to-poly chain. But perhaps using memory read/write could be a solution to my problem if I access the memory directly. Thanks for the tip. If I find something that works with the poly+mono only, I'll post it here 🙂

rl · 4 Mar 2010

mwvdlee wrote: I'm noticing some weird behaviour whilst processing MIDI messages in both white (poly) and green (gui) at the same time; sometimes messages seem to get mixed up in order. The only reason I can think of this happening would be if the white (poly) is processed in small batches of several samples at once. Is this the way poly is handled?

My interpretation: VST hosts typically setup a thread for sample processing and a thread for GUI processing. For an effect the VST hosts calls a VST plugin function called process() giving an array of samples as an input (where the plugin reads samples) and and array of samples for the plugin to write to. During the call the VST plugin operates on a block of samples. SM as a plugin hands this over to the schematic to be calculated in streams. Midi and green processing is handled in the GUI thread. So I'd wouldn't expect exact timing on events created by the GUI thread as long as you can't create excactly timestamped events (something like "create this event according to the time-position of the 125th sample of the buffer"). There is also the latency issue: samples will be always calculated in blocks "before time" while events created in the GUI thread will be fired immediately.

mwvdlee · 4 Mar 2010

rl wrote: mwvdlee wrote: I'm noticing some weird behaviour whilst processing MIDI messages in both white (poly) and green (gui) at the same time; sometimes messages seem to get mixed up in order. The only reason I can think of this happening would be if the white (poly) is processed in small batches of several samples at once. Is this the way poly is handled?

My interpretation: VST hosts typically setup a thread for sample processing and a thread for GUI processing. For an effect the VST hosts calls a VST plugin function called process() giving an array of samples as an input (where the plugin reads samples) and and array of samples for the plugin to write to. During the call the VST plugin operates on a block of samples. SM as a plugin hands this over to the schematic to be calculated in streams. Midi and green processing is handled in the GUI thread. So I'd wouldn't expect exact timing on events created by the GUI thread as long as you can't create excactly timestamped events (something like "create this event according to the time-position of the 125th sample of the buffer"). There is also the latency issue: samples will be always calculated in blocks "before time" while events created in the GUI thread will be fired immediately.

Long and short of it; I must try and find a way to share data amongst multiple poly's without going to green. The memory thing may work, but I haven't had the time to try it out yet.

MegaHurtz · 4 Mar 2010

study the code some more?

mwvdlee · 6 Mar 2010

Well, it wasn't easy and I had many, many crashes (and still not 100% sure it's stable), but here's part of the solution to my problem:

This module keeps track of number of times each individual note is triggered.

That isn't the full solution to my problem yet, but it's a fundamental part; with the counter I can make a Code module that, for each new poly, stores the current trigger count of the note that can kill it. Now just check whether the count has changed from the stored one and if it has, the note has been triggered since this poly was started.

If you could trigger multiple MIDI notes at the exact same time, it may mess up because the poly-to-mono adds up everything, but by itself MIDI never seems to receive multiple notes. I'm still looking into a way how I could ensure this never happens. Detecting this situation is easy (just have each poly send "1" at start and use poly-to-mono to check whether the combined sum > 1), handling it properly less so.

MichaelBenjamin · 6 Mar 2010

nice work, i put up a quick 4 poly version of it, but this got a little bug which i dont understand atm, the first voice counts fine, but voices 2-4 shortly show the previous value.. maybe it got something to do with the hop.

mwvdlee · 6 Mar 2010

MichaelBenjamin wrote: nice work, i put up a quick 4 poly version of it, but this got a little bug which i dont understand atm, the first voice counts fine, but voices 2-4 shortly show the previous value.. maybe it got something to do with the hop.

I don't see anything wrong as you describe with voices 2-4. The readout seems to indicate the correct number without any visual "oddities". How long would you guess the delay is? I can't seem to replicate it, but you could just change the hop size to confirm you suspicions.

I don't quite understand why you'd want this in 4-poly. Perhaps I'm missing something important? It does seem to fix the bug with simultaneous notes a bit; my version could only handle one note at a time, yours can handle four. Any more and the extra notes are still not counted though, so it's not a perfect fix yet.

I do like having shared memory for the DSP stuff, perhaps it's a good idea to start a new topic and explore the possibilities?

p.s. Here's a fun little fact; the hop(n) command is only limited to 4096 is code. In assembler you can replace it by, i.e. 65535, and it works just fine. Don't know what the maximum limit it, but probably way more than 65535 even 😉

trogluddite · 7 Mar 2010

mwvdlee wrote: Don't know what the maximum limit it, but probably way more than 65535 even

I would guess it's a normal 32 bit integer value (31bits if you discount the sign) so 2^31 wuold be the max - my rough and ready maths (at 44.1k sample rate) makes that a piece of code that would run once every 13.5 hours!!

Acrobat · 7 Mar 2010

mwvdlee wrote: I'm still looking into a way how I could ensure this never happens.

it never of course, midi is serial