if you are holding notes and you bend the pitch upwards, do you want the held notes to switch off and on again as they scan upwards chromatically? or would it be better for the pitch bend message to only transpose when a note is first played?

i think in either case, you will need to store the on/off states and transposition value of all notes in a table so that the transposition doesn't cause note off events to send to the wrong note number and cause notes to hang.

you could have a table with 128 values. when a normal note on comes through, the value of that index changes to 1, then to 0 when the note is released. you could also store transpositions in this table, 1 = no transposition, 2 = +1 semitone, -2 = -1 semitone, etc.

if you want to transpose held notes you would need to scan and update this table multiple times during a pitch bend. it's possible that would be limiting.

hi. i finished 5 camomile projects last year. i wanted to wrap them in pd vanilla patches and expose the controls so it would be easier for pd users to port them into other setups.

they can be downloaded individually here, and there are descriptions of the camomile patches on this same page:

https://sympathykeyroom.com/synth.html

the envelopes in these synths function, but i am not satisfied with them any more. i am working on some projects with better envelopes and voice stealing. should be posting that soon.

i am working on a much needed update of Ed Myrol because there are some serious flaws in the voice design. i will post that eventually. for the time being, this version still has a charming sound.

I use that method. I've had to add an extra delay in ms to avoid clicks when the dsp switches off in a voice. I adjust while playing until problems stop.

You can do this and still use vline~ in your patch because the output always starts exactly one block after receiving input.

i have to update!

long live bob~

shoot! i'm still using vanilla 0.47.1 out of laziness. i haven't installed any externals, but i think bob~ was a packaged external like sigmund~

possibly it can be found via Deken?

yes, you can definitely patch this up.

will you want to queue note offs so that all notes release eventually, or should notes hang after at least two are pressed and then released?

a 128 position array can keep track of which notes are held. you can use a note counter and once it reaches 0, send note offs for each note the array recorded.

you may also want to look at the help file for [bag ]. you can flush it when the note counter reaches 0. i am nervous about using [bag ] for reasons i don't remember.

Hi. I made this patch for you. It plays a sound into a buffer at a pitch you specify, then midi input transposes the buffer down. There are some funny consequences of this setup.

buffersynth.pd

it's messy, but possible, to use a single sample delay with clipped feedback to generate a typical compressor envelope. i don't have this patched up in an intelligible way but i could clean it up if anyone is interested.

I've been doing it like this lately, but i'm curious if there's a better way

using [rzero~ 1] with [samphold~ ] might be interesting.
or rather, not samphold~ but i'm not sure what...

i think a lot of discussions about this either here or on the list end up concluding that it is preferable to just rebuild the LFO using vline~, so you know ahead of time when it will change direction. Are you using an LFO that has too complex a pitch modulation to build it with vline~?

yep, there's several ways to do it, but you can start by putting a message box in front of both you line~ objects with the message $1 5

[tabread mutes]
|
[$1 5 (
|
[line~ ]

this should make the volume ramp up or down over five milliseconds when it changes. the line~ object will change to the new value over the time specified by the second number in the list at the left inlet.

the clicks you're getting now happen when the osc~ output is far from 0 at the block boundaries. the line~ objects change their output abruptly at the block boundaries and the sound of the sine wave going from some value to 0 immediately sounds like a click transient. with a 5ms time value, the line~ will instead wait for a block boundary, and then begin changing to the new value over 5ms.

on second thought, i'm pretty sure i'm wrong about this one, because of the fixed ratio operators in the tx81z/dx11

txdxdetune.pd

this patch is still kind of interesting and you would save a good bit of processing. on a 4 op 8 voice synth, you would save 23 phase accumulators total, but have reduced control over individual operator pitch.

yep, this creates two sine tones, 2 Hz apart...

the phasor~ 2 would be common to all voices

in polyphonic material it might be fine, as long as each voice received an arbitrary dc offset. but it would spoil per-voice pitch envelopes. the dx11 has pitch envelope, but it definitely targets the pitch of all operators at once.

thank you!!

okay, yeah. actually now that i understand better how vline~ works i guess it would be possible to phase sync without using the sample and hold method. if i'm sending pitch with a vline~ i have time to send a phase 0 message to my phasors. i should revise some of my lfo designs that use sample and hold reset for no benefit.

i just need to make sure i'm not reseting phase on a stolen note to avoid clicks.

i used to have a tx81z and a dx11 and i have a strange suspicion. they let you set a ratio for operator pitch, as normal. then, they let you choose one of 7 options for oscillator detune. you do not select detune in cents. this could mean that each voice only has one phase accumulator/phasor-like osc. the ratios are set by multiplying and wrapping that ramp before a sine shape. when detune is selected, it's possible the synth uses one of six cheap low-frequency beating oscillators to send to the phase inputs of all the operators that are set to be detuned.

hey! yep, i ran multiple instances of tabsend/recieves and then the delays, both in block~ 1 and it looked like the delays were slightly less cpu heavy, but i didn't check RAM. i'm still a little paranoid about cross modulation- like what if the fundamental gets negated if certain modulation is running 1 sample behind. but that's probably nonsense! especially since the phasor~s aren't phase synced anyway

i'm working on something now that i'm really excited about that has a simple 2op structure that feeds back into itself. I love fm feedback sounds so much.

the rzero~ -1 i copped from this thread, https://forum.pdpatchrepo.info/topic/6185/feedback-fm-algorithm/10

i wonder if there is an effect of putting that in front of the feedback delay

Here's another take that might be lazy and dumb, but i have a suspicion that it is fine:
pmmatrix.pd

needs a lot of work before it will fit into a project. normal modulation from one operator to the other sounds fine to me. feedback sounds about right too. keeping the buffer on the delays down to 0.05 should be fine for sample rates down to 22050.

the method weightless uses here is really good! https://forum.pdpatchrepo.info/topic/10745/3-op-fm-synth-with-mod-matrix/3

i opened up that patch and the crux of it is using tabsend~ and tabreceive~ with a block~ 1 1 1 to delay the outputs of each operator by one sample. (i am wondering now if this is a better method to get a one sample delay than using delwrite~ and delread~, i need to do some testing. at the very least, it's wasteful to use a delwrite~ with a buffer of an entire 7 ms)

the tables that tabsend~ and tabreceive~ use store only a single value each.

so each operator receives fm input one sample later than it arrives at the fm input. this is a totally negligible delay for normal fm, and feedback is only possible this way, because the phase can't be calculated and take feedback into account. the feedback must be from 1 sample in the past because otherwise it hasn't been calculated yet.

the $ arguments in the patch make it easier to make separate multiples of things. if you have time to go through the documentation about abstractions and arguments, that will be very useful for synth stuff generally.

i can draft up something that breaks down the tabsend/receive method this evening, but you should spend some time with the patch by weightless because it's great

Hi everyone. I have frequently revised designs for polyphonic envelopes. i've often misunderstood things about vline~ and scheduling voices in such a way to avoid unwanted clicks while also keeping things on time and snappy.

i'd be really happy to know what your methods are for envelopes.

i submit this patch, a reflection on envelope practices and how i address certain challenges. envwork.pd

this patch makes these assertions:

1- because vline~ maintains sample accuracy by scheduling events for the next block, you can switch dsp on in a subpatch with block~ while sending a message to vline~ and the dsp will be active by the start of the vline~ output. This also works if you need to configure a non-signal inlet before triggering a voice. send a message to such an inlet concurrently with a vline~ message and the parameters will update on the block boundary before the vline~ plays.

2- accounting for note stealing can cause issues in a polyphonic patch. if the stealing note has a slow attack and the envelope of the stolen note is not closed, there will be a click as the pitch of the new note jumps. the voices in my patch apply slight portamento to smooth out this click. if, however, the attack time of the stealing note is faster than this slight portamento it is counterproductive and will soften the attack of stolen notes. Stolen notes need every bit of snap they can get because the envelopes may be starting at a non-zero value. so i limit the time of the portamento to the attack time.

3- to make sure a note that is still in its release phase is treated as a stolen note, it is necessary to monitor the state of the envelopes like so:

switching the dsp off too close to the end of the release causes clicks. after testing, my system liked a full 50ms of extra delay after the end of a release before it was safe to switch off dsp. I don't think this is attributable just to the scheduling delay of vline~ but it's a small mystery to me. possibly there's a problem with my voices.

This all gets a little more complex when there are multiple envelopes per voice. The release time that affects the final output of the voice must reset all envelopes to when it is finished and before dsp is switched off. Otherwise an envelope with a long release affecting something like filter frequency can be held at a non-zero value when dsp is switched off and spoil the starting state of the vline~ on a new note.

finally, on vline~ and sample accuracy and timing, let me type out what i believe is the case. i could be wrong about this. if you programmed a synth using line~ for the envelopes, it would be faster than vline~ but not all notes equally faster. all notes would sound at the block boundary. Notes arriving shortly after the last block boundary might take 90% of the block period to sound. notes arriving just before the block boundary might take 10% of the period to sound.

vline~ will always be delayed by 100% of the block boundary. but the events will be scheduled sample-accurately, so the vline~ will trigger at exactly the real time intervals of the input. a synth with line~ envelopes will trigger any two events within a single block at the same time.

this should mean that vline~ envelopes can be accurately delay compensated and stay absolutely true to input timing, in the case of something like a Camomile plugin.

however, if one was to build a synth for something like a raspberry pi that will act as hardware, would it be better to use line~ envelopes and gain a little bit of speed? is the restriction of locking envelopes to block boundaries perceptible under normal playing conditions?! i could test some midi input and see if the notes in a chord ever achieve a timing spread greater than the block period anyway...

Hi! I've done some fm with feedback lately for a Camomile plugin. If you don't mind doing archeology, the patches are here: https://patchstorage.com/pmer/

I think the best way to do multiple operators with feedback is something like this:

your matrix will need to be able to detect feedback paths and route them correctly through the single sample delay. it's possible if an oscillator is fed back into itself and also routed into an earlier oscillator that then feeds the first oscillator you will end up stacking delays? is this true?

I've been putting different waveshaping logic in multiple subpatches, then using switch~ to activate dsp on only the one that is selected. This seems to have worked really well for me! sometimes i use it without anything between the inlet~ and outlet~ in order to route a signal to one of multiple destinations.

a more sophisticated approach might have a second subpatch inside each subpatch that fades out and in the signal over 10 ms or so when the selection changes. for my taste that is a little over the top.