randomized multivoice to poly

[KG_is_back]

A reworked version of one of my previous projects. Usually when you use multivoice to poly, when you press a key (send in note) ti will create all voices for which the note lies in range. That is however not always desirable. For example in drum sampling you usually have many samples and you what to randomly pick one from the valid samples.

That is exactly what this thing does. Uses my memin workaround to create memory block, where every voice writes its voice tag when key is pressed (31 places for voice per key). Those multivoices are killed instantly.
Second midi to poly (normal one - not the multivoice) then calls the number of voices saved for that key, randomly picks one (based on the randomizer mono input) and resets the memory at that key. The schematic is not 100% stable (because of the mentioned memin workaround I've mentioned) yet, so use it with care.

Also a bonus - screen for editing key and velocity ranges. You can change the voice count, scroll through the voices (indexing starts at 0 and ends at no.of voices -1). and individually edit key and velocity range per voice (by drag upper left / bottom-right corners). If someone would be so kind and redo the module in ruby, I'd be very grateful.

[Exo]

Will take a look at this when I get to my Flowstone machine at the weekend, particularly interested in looking at how you write the voice tag to memory.

I am working on something at the moment which takes the phase from each osc and writes it to memory when the voice finishes. Then when a new voice is started the osc phase will start from where it left off. Bit of a hack and don't have it working quite right yet but will be interesting to see your approach of extracting values from poly.

[KG_is_back]

The principle is a little hacky indeed. I have used analyzer, to show code of module that is connected to it. When you connect wave read prim it shows the assembly code of that prim. That is where I have found the address of pointer to the memory.
It is always at the same spot, so I used string extract to get it out (new version uses ruby to do that) and use the binary structure of that integer as a float (basically looks like a random number in float - it is an integer in reality)

Then you can use this address within your assembly codes

Code: Select all

streamin Address;

int pointer=0;

mov eax,Address; //reads the address of the pointer
cmp eax,0;
jz ERROR; //this just checks if the address has been provided - prevents most crashes
mov eax,[eax]; //move data at the addres to eax - it should be the pointer of the memory
cmp eax,0;
jz ERROR; //doublechecks :-D
mov pointer[0],eax; //store the pointer

//example code how to read/write memory
mov eax,pointer[0];
add eax,intINDEX[0]; //add the index to the pointer... note that each float is 4 bytes wide, so Index must be multiplied by 4 (or bitshifted left by 2)
fld [eax]; //load data
fstp Temp[0]; //save the loaded data to variable
fld Temp[0];
fstp [eax]; //the same other way around - writes Temp[0] to memory

movaps xmm0,[eax]; //note that this will load 4 floats = 16bytes
movaps [eax],xmm0; //you can also write to memory

mov eax,[eax]; //this was already shown above - moves data at address [eax] to eax

ERROR: //here the code jumps if no address is provided - attempt to read/write data to random location (especially position "0") most likely cause crashes


for the poly section, well... all you need to do is use the same memory location for all SSE channels.

[adamszabo]

I am working on something at the moment which takes the phase from each osc and writes it to memory when the voice finishes. Then when a new voice is started the osc phase will start from where it left off. Bit of a hack and don't have it working quite right yet but will be interesting to see your approach of extracting values from poly.

Ah, please post that when you get it working! I would love to see how you did that, it has been my quest for ages to get some free running oscillators in poly.

[Exo]

Hacky indeed! Thanks for the run through. I am using the mono write mem primitive (forgot it's exact name) in the poly section.

[Exo]

I am working on something at the moment which takes the phase from each osc and writes it to memory when the voice finishes. Then when a new voice is started the osc phase will start from where it left off. Bit of a hack and don't have it working quite right yet but will be interesting to see your approach of extracting values from poly.

Ah, please post that when you get it working! I would love to see how you did that, it has been my quest for ages to get some free running oscillators in poly.

Of course I will post it

[KG_is_back]

Here... this one should work. It saves phases per pitch - not per voice... if you have more voices with same pitch the newest voice will override phases of others. Also if you press different key, it will have its own phase storage.



Proper way to do it would be to write the phase in a last place in queue on the last sample and pop the first value of queue on first sample. We may use the mem as a queue buffer using two first values as "first" and "last" positions in the queue and others as a buffer. The only problem is, we need a last-sample-detector... in synth with custom envelope this should not be a problem because we may use the same boolean stream to activate phase-push and envelope-end.

[Exo]

Just hand a look at your drum sampler schematic , and very interesting stuff nice work. Like the use of two voice to polys which is of course legal as long as the streams don't 'touch'

Love seeing Flowstone made to do things that 'can't be done'

[KG_is_back]

Just hand a look at your drum sampler schematic , and very interesting stuff nice work. Like the use of two voice to polys which is of course legal as long as the streams don't 'touch'

Love seeing Flowstone made to do things that 'can't be done'

It also should work in Synthmaker too. However not the current version, because it uses ruby to convert int->float without changing binary structure. However my earlier versions done this in green & assembly and worked too, so it is Synthmaker compatible.
I have made an early version quite some time ago, using trogs float array to mem. He created a ruby code, that creates a sample frame of predetermined size and passes the pointer as two 16bit integers (which can be lossless converted to float) and also the size.
It worked pretty much the same way and crashed pretty much the same way
This version uses my mem->pointer which gives a little more freedom as you can use waves and mems from various sources and of various sizes and types (even mem-array version work).

Also note, that this version supports only notes 0 to 255. Negative note numbers (pitch) and numbers above 255 may crash. This is due to a fact, that the memory that holds voices has only 256 "pitch slots" trying to input pitch outside that range causes the code to write/read data outside the array. If you're lucky that area in RAM holds no data and the schematic will work - if you write/read area that is reserved for different essential data ...well...crash...

[Exo]

Just hand a look at your drum sampler schematic , and very interesting stuff nice work. Like the use of two voice to polys which is of course legal as long as the streams don't 'touch'

Love seeing Flowstone made to do things that 'can't be done'

It also should work in Synthmaker too. However not the current version, because it uses ruby to convert int->float without changing binary structure. However my earlier versions done this in green & assembly and worked too, so it is Synthmaker compatible.
I have made an early version quite some time ago, using trogs float array to mem. He created a ruby code, that creates a sample frame of predetermined size and passes the pointer as two 16bit integers (which can be lossless converted to float) and also the size.
It worked pretty much the same way and crashed pretty much the same way
This version uses my mem->pointer which gives a little more freedom as you can use waves and mems from various sources and of various sizes and types (even mem-array version work).

Also note, that this version supports only notes 0 to 255. Negative note numbers (pitch) and numbers above 255 may crash. This is due to a fact, that the memory that holds voices has only 256 "pitch slots" trying to input pitch outside that range causes the code to write/read data outside the array. If you're lucky that area in RAM holds no data and the schematic will work - if you write/read area that is reserved for different essential data ...well...crash...

Good point about the "pitch slots" the free running osc I just posted uses a similar concept but only has 128 slots so will suffer the same issue although limiting the index to 0...127 will suffice to fix that.