Prototype - Free running poly oscillators

[Tronic]

The module named "create voice ID," the S&H, i think does not seem to work well for this scenario,
when you play notes, if they release some, not all, and not in the same sequence as they were played,
then you now play other note, it does not occupy a position of free voice, but it overwrites the last played,
as in mono behavior.
I hope that I managed to explain.

[adamszabo]

I sort of did it! To be honest I dont really know what I did, I checked over the assembly code, and reversed the order of the read and write and now it works for some reason! Btw what does this part do exactly?

Code: Select all

  pslld xmm0,2;
  paddd xmm0,addr;

Also, I still think using the envelope control to trigger the last sample point to store the data is not the best way, sometimes when you switch from one note to another it makes a clicking strange artifact, I can only suspect it comes from this method.

[Exo]

The module named "create voice ID," the S&H, i think does not seem to work well for this scenario,
when you play notes, if they release some, not all, and not in the same sequence as they were played,
then you now play other note, it does not occupy a position of free voice, but it overwrites the last played,
as in mono behavior.
I hope that I managed to explain.

Thanks, yes I understand what you mean.

The voiceID method is pretty dumb. I will have a go at a more intelligent version. I would just need to keep track of the active and free voices then assign a free voiceID to new notes played. Would use more CPU but hopefully won't be a noticeable increase.

[Exo]

I sort of did it! To be honest I dont really know what I did, I checked over the assembly code, and reversed the order of the read and write and now it works for some reason! Btw what does this part do exactly?

Code: Select all

  pslld xmm0,2;
  paddd xmm0,addr;

Also, I still think using the envelope control to trigger the last sample point to store the data is not the best way, sometimes when you switch from one note to another it makes a clicking strange artifact, I can only suspect it comes from this method.

Ok great thanks Adam (call me Tom if you like ), cannot test your file till tomorrow though now.

I agree the way it is now is not the best way. The phase is saved as soon as the release starts instead of finishes. One way could be to modify an envelope and add an output boolean for when the env actually finishes. This way you can have a bit of a release and the phase will save exactly when the env ends.

Or could do it how I had it initially, basically let the phases be constantly written and then when the voice dies the writing will stop so then we know we have the exact phase when the voice died. Then we could read and sample and hold the phase when a new voice starts.

Regarding that code, the first line is shifting the index 2 places to the left which is basically multiplying by 4, then this is added to the buffer pointer giving the correct index into the buffer.

The pointer holds the start address of the buffer this is an integer such as 12340 which is just a location in memory. Each location represents a byte. Floats are 4 bytes long so to get the correct location for each float we multiply the index by 4 and add it to the pointer address.

[adamszabo]

Or could do it how I had it initially, basically let the phases be constantly written and then when the voice dies the writing will stop so then we know we have the exact phase when the voice died. Then we could read and sample and hold the phase when a new voice starts.

Whooho, I tried it and it works! I managed to get rid of the envelope thing, and now its much simpler and i am pretty sure THIS is the way it works in other synths. The last problem is if you keep repeating a single note, on the scope (and you can hear it) you can see that you get this ugly snap sound (it seems like the first sample), I have no idea where it comes from perhaps the voice management part. Maybe we should investigate there.

Regarding that code, the first line is shifting the index 2 places to the left which is basically multiplying by 4, then this is added to the buffer pointer giving the correct index into the buffer.

The pointer holds the start address of the buffer this is an integer such as 12340 which is just a location in memory. Each location represents a byte. Floats are 4 bytes long so to get the correct location for each float we multiply the index by 4 and add it to the pointer address

Great got it thanks!

[Tronic]

After a bit of thinking,
I believe the module to create the id of the voices is superfluous,
directly connecting the output voice tag works well,
of course I think Exo has opted for this solution to have a correct view of vocies,
but for the correct assignment of vocies in the memory for me is not needed,
otherwise you can not use other functions related, for example. Hold stolen .. etc..

[Exo]

Or could do it how I had it initially, basically let the phases be constantly written and then when the voice dies the writing will stop so then we know we have the exact phase when the voice died. Then we could read and sample and hold the phase when a new voice starts.

Whooho, I tried it and it works! I managed to get rid of the envelope thing, and now its much simpler and i am pretty sure THIS is the way it works in other synths. The last problem is if you keep repeating a single note, on the scope (and you can hear it) you can see that you get this ugly snap sound (it seems like the first sample), I have no idea where it comes from perhaps the voice management part. Maybe we should investigate there.

Regarding that code, the first line is shifting the index 2 places to the left which is basically multiplying by 4, then this is added to the buffer pointer giving the correct index into the buffer.

The pointer holds the start address of the buffer this is an integer such as 12340 which is just a location in memory. Each location represents a byte. Floats are 4 bytes long so to get the correct location for each float we multiply the index by 4 and add it to the pointer address

Great got it thanks!

Good work, thanks

Yes I have noticed the snapping, not sure yet exactly what is causing that. I got up late so not had a proper go at fixing yet ( I generally spend an hour before work on my computer)

If you get chance before me can you try removing the phase input to the saw and see if it still happens? Just want to rule out it being something other than the phase writing code.

[Exo]

After a bit of thinking,
I believe the module to create the id of the voices is superfluous,
directly connecting the output voice tag works well,
of course I think Exo has opted for this solution to have a correct view of vocies,
but for the correct assignment of vocies in the memory for me is not needed,
otherwise you can not use other functions related, for example. Hold stolen .. etc..

It is needed for it to be truely polyphonic.
Just using the voiceTag is fine when just pressing one note at a time. Each note will start at the exact phase where the last note played left off, which will sound right when only pressing one note. Now when pressing a chord each note of the chord will start at the same phase.

Unless of course each note of a chord starting at the same phase is more desirable? Expected?

[adamszabo]

Unless of course each note of a chord starting at the same phase is more desirable? Expected?

Nope, its not expected, the way we have now is correct but need a nicer method than using that mono primitive.

Ok I found the spike bug, it seems when I make the ramp and the saw inside the code it makes the click for some reason. If I move the (ramp*2-1) to make a saw, out of the code, the spike is gone. I seriously have no idea why its doing that, but is it possible to fix this within the ramp code? I made a very low frequency so we can see the value rising, and if you connect the two different outputs to the combiner you can see and hear the difference.

Btw, now that we are continuously writing the phase, is it important to have the "skip1" etc.. comparisons from the writing part? I wanted to remove that but flowstone crashes.

[Exo]

Unless of course each note of a chord starting at the same phase is more desirable? Expected?

Nope, its not expected, the way we have now is correct but need a nicer method than using that mono primitive.

Ok I found the spike bug, it seems when I make the ramp and the saw inside the code it makes the click for some reason. If I move the (ramp*2-1) to make a saw, out of the code, the spike is gone. I seriously have no idea why its doing that, but is it possible to fix this within the ramp code? I made a very low frequency so we can see the value rising, and if you connect the two different outputs to the combiner you can see and hear the difference.

Btw, now that we are continuously writing the phase, is it important to have the "skip1" etc.. comparisons from the writing part? I wanted to remove that but flowstone crashes.

The osc should be fixable within the code I will take a look.

Regarding the writing I tried removing the skip stuff but that messed the phases up so I put it back. Currently the gate input is ensuring that the phases are only written while the note is held, which is working ok for what we are doing. Currently not entirely sure why the gate would be needed, when a voice stops it should just stop writing, at least in theory.

Yes going forwards I would like to create a more intelligent voice management system that is mimicking exactly how the voice system works internally. I think this would open up lots of possibilities. I am currently contemplating possible solutions. I will need to keep a track of when voices are killed so I will have to write my own env module to replace the env primitive in the envelopes used. This env module would have access to the list of active voices and update it accordingly. I think that would be the only way to create proper voice management.