Is it possible to create consisten clicks?
Hi there! Please dont be to rude to me if this might be a stupid question (max beginner here) but is it in any ways possible to trigger oscilators in max while producing a consistent click? From my understanding this should be possible whilst resetting the phase of a cycle at a consistent position of the phase wilst triggering its volume envelope at the same time. This works kind of but the clicks still vary and i dont really understand which fact is causing this. Any help is deeply apreciated. thx!
Where are the clicks in your example patcher?
Your understanding seems right to me, but I can't relate to the example patcher you provide.
if you want to trigger click use click~ object
the correct patch is in the topic now, sorry for that. ok i just found out that setting down the default vector size in the audio set up made all behave like i expected it. i am such a noob haha. how do you guys approach these settings there? Is it a good idea to have the signal and i/o vector size quite low? what are your default settings?
Lowering the default vector size might help but won't solve the heart of the problem.
In your case, to get sample-accurate envelop triggering, maybe try to stay in audio domain (ie. ~ objects). For that purpose you could use [adsr~] instead of [curve~].
Thx for your reply TFL. How would you reset the phase of the cycle in this case??
the timing issue is caused by the egde object: if you want things sample-exact you are supposed to use only signal objects. (as you already found out it gets much better when using a very small vectorsize, but that is still not perfect)
note that since the latest max update phasor~ also accepts a click~ style click in the left inlet (thanks to raja for this wisdom.) but eventually it is more safe and obvious to copy one the of the various examples you should find via forum search, where phasor is used together with click~, sah~, and %~ in different combinations.
the conversion between what in the analog world is called a trigger, a gate, and a state transition from nonzero to zero is a bit messy in certain programming languages, but it is doable.
in your case you might even find a way how to avoid the need of re-syncing - by keeping the envelope trigger and the oscillator frequency in sync all the time... by changing the multiplicator for both of them.
if you alway bind the faster phase accumulator to the slower one, you do not even need the rate~ object family to link two phasors.
furthermore you should consider to use a signal envelope (write the curve~ output once to a buffer~, then use the phasor signal to read the envelope from the signal buffer out using something like wave~ - or actually another cycle~: a repeating envelope, an LFO and a noisegenerator can be technically all the same!)
Hi Roman! Thx for your in depth answer! Will dive into this now!
Hi Roman, I am struggling with a similar problem. However edge, and some other objects, are supposed to be sample accurate now so I am not sure about your analysis.
https://docs.cycling74.com/legacy/max8/vignettes/audio_sampleaccurate
what are your default settings?
i keep signal-vector and i/o vector both around 64(but if i have troubles with CPU, then i bump up to 128), and then i'll always leave 'Overdrive' and 'In Audio Interrupt' at 'On'.
i choose these settings mainly because this is the equivalent of how PD and Supercollider both work by default. But also, because I've found whatever i can do with these settings is a good indicator of what my computer can do with audio, in general(the only time i bump vector size down below 32 is if i have to test something for event-timing, and the only time i bump vector size above 128, is if i'm using expensive processing like FFT, etc... ...i also don't turn 'Overdrive' or 'InAudioInterrupt' off, unless i am making something that is very CPU expensive and doesn't require audio-timing, such as when i'm experimenting to learn Jitter/video-processing... or... another context you might not need 'InAudioInterrupt' is using max to process only midi/usb/serial data, etc...)
____________________
separately, @BaekSantarek makes an interesting point about how the docs read:
struggling with a similar problem. However edge, and some other objects, are supposed to be sample accurate...
https://docs.cycling74.com/legacy/max8/vignettes/audio_sampleaccurate
i think nowadays, computers might be getting fast enough to allow this, however, the docs are also written somewhat confusing, as this language(just above where they list 'edge~' as being among the objects that 'generate events sample-accurately'), seems to contradict the idea that any of those objects are 'sample-accurate':
In Scheduler in Audio Interrupt, the scheduler for the vector of audio that snapshot~ sampled runs before the audio vector is processed. This means the events generated by snapshot~ will be delayed by exactly one signal vector's worth of real time.
^it's as if the docs are saying the event-objects it lists are sample-accurate, only because they have a sample-accurately predictable latency(?)
i dunno why they write it so confusing, but when i want absolutely reliably sample-accurate timing, then i don't trust event objects to behave like signal objects. i only use signal objects for sample-accuracy, because the way that 'sample-accurate' event-objects poll the scheduler to access audio-signal data will follow this 'priority' that can lead to a vector's worth of latency.
he somehow has a point that i was inaccurate above, but like raja says... the "sample accurate" in these docs reads bit misleading... in fact the timing you get is only "scheduler accurate", isn´t it. :)
one might argue that the rounding errors at the domain change are irrelevant -and that "interrupt on" should be the default setting in sequencing contexts - but the latter is a condition to make edge~ "scheduler accurate" ... and even if the condition is met it is still not 100% the same thing as a pure signal network or a pure metro patch... and therefore the idea that "it now will work" (in the sense of no longer beeing dependent of the vectorsize, as we all claimed above) contains traps.
1.) data gives you the highest resolution for timed events but it might fail to deliver them in time.
2.) only samples signals are sample exact
3.) and converting from signal to data rate ist still only a compromise, yet today much better than in the past (because the output does no longer depend on the vectorsize when interrupt is on.)
i had yet to investigate how the new options of the max scheduler on v9 comes to play here.
because one thing is also clear: in pre v9 schedulers the data rate timing accuracy also depends on the vectorsize when audio is on, even in a data-only patch.
one last thing, in case it helps, here's a signal-only version of the original patch:
(to use zigzag~, i had to guess as to how to recreate the exponential decay... squaring the output twice seems to get it close... not exact, but hopefully the general idea becomes apparent here... [edit: you can also keep things simple by using 'slide~ 1 1000' (or similar timing args) instead of zigzag~])