raytracer

Max newbie here. My first project is to create a sample accurate sequencer to trigger drum samples. So far I've created a sample accurate [metro] object using gen~. (The gen~ object sends out a 5 ms pulse every X milliseconds.)

I've also built a sample player instrument using [poly~]. The sample player instrument is currently triggered with "bang" messages. Each time a [poly~] voice is triggered, all currently active [poly~] voices are sent another bang to force an internal amplitude ADSR envelope to enter it's release stage. The active voice is muted when the ADSR envelope finishes.

Triggering a [poly~] object with bang messages isn't sample accurate. I can't figure out how to trigger a [poly~] voice from a pulse signal.

1) The [edge~] object can detect pulses and send bang messages but again this isn't sample accurate.

2) Is there a way to detect where the pulse happens in a signal relative to the signal vector boundaries? Something like [edge~] but it would also report that the trigger pulse happens in X samples. This would allow voices to compensate internally when triggered with a message.

3) The voice objects could be manually duplicated instead of using the [poly~] object. I would then need something to handle voice allocation sample accurately. Does something like this already exist?

I've googled but am obviously using the wrong keywords as nothing is showing up.

I've also built a sample player instrument using [poly~]. The sample player instrument is currently triggered with "bang" messages. Each time a [poly~] voice is triggered, all currently active [poly~] voices are sent another bang to force an internal amplitude ADSR envelope to enter it's release stage. The active voice is muted when the ADSR envelope finishes. 

Triggering a [poly~] object with bang messages isn't sample accurate. I can't figure out how to trigger a [poly~] voice from a pulse signal. 

1) The [edge~] object can detect pulses and send bang messages but again this isn't sample accurate. 

2) Is there a way to detect where the pulse happens in a signal relative to the signal vector boundaries? Something like [edge~] but it would also report that the trigger pulse happens in X samples. This would allow voices to compensate internally when triggered with a message. 

3) The voice objects could be manually duplicated instead of using the [poly~] object. I would then need something to handle voice allocation sample accurately. Does something like this already exist? 

I've googled but am obviously using the wrong keywords as nothing is showing up.


how-to-trigger-poly-object-sample-accurately

i haven't experimented enough with this. with voice-muting, always seemed impossible(once you mute a voice, dsp is turned off, so you can't get sample-accurate with no signals running... whenever i needed sample-accurate triggering of voices, i simply left all voices on, even when not playing :p).

(edit: i used to think you could mute thispoly~ with signals, thought maybe that might be one thing to try... but now i see that only sets the busy state, so you can't send a muting signal directly to voices either...)

so... here's also a bump to the thread for other ideas...

Is it possible to send a audio signal to a specific voice in the same way messages can be with "target X"?

Is it possible to send a audio signal to a specific voice

sort of... if you don't have too many voices, you can create 'in~'s within your poly~ voice for as many voices as you have, then put a selector~ within your poly~ voice at these in~s, and have it open upon initialization based on voice number to just one in~(voice number from thispoly~ to selector~).

a bit overkill(each voice will have many unused inlets :p)

another way, which i've heard(using send~/receive~ within poly~) is not as safe (but personally haven't run into problems with yet), is to use thispoly~'s voice number to sprintf-set a receive~ name like so:

if you decide to use that last one, be sure to test it out thoroughly before performing with it ;)

sort of... if you don't have too many voices, you can create 'in~'s within your poly~ voice for as many voices as you have, then put a selector~ within your poly~ voice at these in~s, and have it open upon initialization based on voice number to just one in~(voice number from thispoly~ to selector~).
a bit overkill(each voice will have many unused inlets :p)

if you decide to use that last one, be sure to test it out thoroughly before performing with it ;)


After fair bit of experimenting and searching the forums I think I've found a way. I've made one object that can detect when a pulse occurs with respect to the signal vector boundaries. Using this info, pulses can be translated to bang messages with a matching delay time. A second object receives the bang + delay_time message and outputs an audio rate pulse (delayed by the delay_time amount). This technique does introduce a latency of two signal vectors however.

i was about to suggest gen~ but then took a quick look and see that's how you're doing it anyways.

i'll keep taking a look back at this as i find more time(i just thought of some more ideas: maybe a master poly~ for the clock that stays on all the time with its internal vector-size set to '1' and local-scheduling turned on, then within that would be further nested poly~s for your synth voices which could be muted/unmuted...)

but in any case, nice work! (especially on calculating that within-signal-vector delay)

i was about to suggest gen~ but then took a quick look and see that's how you're doing it anyways.
i'll keep taking a look back at this as i find more time(i just thought of some more ideas: maybe a master poly~ for the clock that stays on all the time with its internal vector-size set to '1' and local-scheduling turned on, then within that would be further nested poly~s for your synth voices which could be muted/unmuted...)

but in any case, nice work! (especially on calculating that within-signal-vector delay)


Nesting poly~s is a good idea. I wonder how that would effect CPU usage?

Here's another example with the audio-rate metro object now triggering a sample player. 

Nesting poly~s is a good idea. I wonder how that would effect CPU usage? 

Here's another example with the audio-rate metro object now triggering a sample player. Audio Rate Sample Triggering.rar


Are these one shot samples? If so, you could fire a single sample pulse that's equal to the voice number and then just use ==~ to trigger the process in the patch. You could use gen~ to make a crude voice allocator. (The catch being that it won't be able to know who is busy...)

I've also used chains of playback objects that pass through triggers to the next object in the chain if they're already playing. Was really interesting for granular, though it was fixed in terms of voice count and muting.

Are these one shot samples?  If so, you could fire a single sample pulse that's equal to the voice number and then just use ==~ to trigger the process in the patch.  You could use gen~ to make a crude voice allocator.  (The catch being that it won't be able to know who is busy...)

I've also used chains of playback objects that pass through triggers to the next object in the chain if they're already playing.  Was really interesting for granular, though it was fixed in terms of voice count and muting.


I’ve also used chains of playback objects that pass through triggers to the next object in the chain if they’re already playing.

It seems all the patches in this thread have dried up over time? For any futurepeople looking for a patch here's what i came up with.

's patch and integrated the jitter-fluid-equation for visuals on a monome grid to create this:

there are 48 voices of this loaded into poly~:

Screenshot 2023-12-02 at 4.00.23 PM.png

(the 'sig_quant' part is a way i thought of to quantize signal clicks with added swing in gen~, but it's nested within the outer 'cax' subpatch that "catches" the click and employs a ducking-window first, so that i can also retrigger the same voice without clicks/pops... the 'rec' subpatcher is a way i record audio into the voice, but then trigger other voices after that(up to 8 in a row) to record at a certain rate(2n)... basically, a way to record a larger segment of music into multiple voices in order to turn that longer-running passage into recorded one-shots of 2n-length divided up among consecutive voices... just an arbitrary setup i chose for beat-based music i'd like to make with this, falling anywhere within the area of 70 to 300BPM... the video above doesn't demonstrate recording as i had added it later)

...because i set the 'ramp~' object with "@retrigger 1", there's actually no real point in setting the busy-state of the poly-voice, but with this basic setup, maybe i can figure out other ways to design the system over time...

Thanks, Everyone! For The Ideas In This Thread ❤️

forgot to post here that i souped up LUVULONGTIME's patch and integrated the jitter-fluid-equation for visuals on a monome grid to create this:


Thanks, Everyone! For The Ideas In This Thread ❤️


ten years later... and i am still not convinced that it makes much sense to have signal accuracy when triggering sampleplayers or envelopes.

metro offers 0.7ms at vs32 or 0.35 ms at vs16, and when you use a signal sequencer instead you can reach an accuracy of incredible 0.044ms, but which then only works within that system, because as soon as you need to triggers things from outside or play those signals triggers to the OTB world, that minor precision advantage of your sample accurate system is gone again.

and then there is the other question, which is how useful it will be to have a pure signal trigger sequencer at all. if you work in all signal, why not just store and send the frequency value already as signal from the sequencer? or the playhead/pitch envelope? or a signal gate?

the original question was a great example for the issues you cause with that; even for turning the voices of a poly~ on and off you already need to convert the signal trigger to a signal gate again.

this is ok, as it is all subjective. there are different paradigms for different individuals that govern what 'makes sense': if you don't perform music like i do, it doesn't 'make sense' for me to trust your idea of how to achieve the best 'feel' for my particular style of performance, since 'feel', not mathematical 'logic', is the most important thing to me.

to explain further, this isn't true in my experience of Max at all:

depending on what you do, metros event-rate-jitter simply adds to more MIDI-and-other event-rate jitters all over this weird Max system(supercollider is, by default, more predictably tight on timing of everything, all around)... 

...i also don't think it should be necessary to have a VS smaller than 32(i prefer 64 or 128) for most things and i like that this allows me to leave 'overdrive' and 'in audio interrupt' off entirely...

...this same computer can then run a synchronized video-patch more easily this way as some of the CPU used for event-rate triggering can be saved for that part as well(though i do things in openGL, there's still some parameter-changes that come from metro-based clocks that are synchronized to the transport)...

furthermore, i'm synchronizing two norns via a Link-based phasor~, a 'pikocore'(which takes the 'pocket-operator'-style clock of an audio-click sent at 2 parts-per-quarter, but also requires the audio-click at 48kHz sent from Max to be widened a bit so that it can be picked up by the pikocore running at 33kHz(specializes in 'lofi' sound)), and a PolyendTracker via MIDI-clock that's spawned from the same phasor~ as everything else:

Screenshot 2023-12-03 at 1.01.06 PM.png

so basically, the system i've created here for synchronizing a finger-drumming patch to a larger setup, where i'm not sure what i'm going to add later too, has been served best by planning it all out, right from the start, based on sample-accuracy(having added audio-recording recently in a certain way, i already found that having everything tied to a sample-accurate clock allowed for me to tie that in with minimal latency on the recording side as well).

the poly-voice number is used to trigger the voice by signal(as Peter described above), and this same number is stored in seq~ for the sequencer... here too, the sample-accuracy served me well by reducing the amount of timing-jitters possible all over the system :)

i've been having this experience with Max for more than 20 years: we can talk 'theory' about patching all we want, but until you actually perform your own vision of music, you don't realize that the 'feel' of the performance is served by something entirely different than some form of 'logic' found in the Max environment 🙃

ten years later... and i am still not convinced that it makes much sense  to have signal accuracy when triggering sampleplayers or envelopes

this is ok, as it is all subjective. there are different paradigms for different individuals that govern what 'makes sense': if you don't perform music like i do, it doesn't 'make sense' for me to trust your idea of how to achieve the best 'feel' for my particular style of performance, since 'feel', not mathematical 'logic', is the most important thing to me. 

metro offers 0.7ms at vs32 or 0.35 ms at vs16, and when you use a signal  sequencer instead you can reach an accuracy of incredible 0.044ms, but  which then only works within that system, because as soon as you need to  triggers things from outside or play those signals triggers to the OTB  world, that minor precision advantage of your sample accurate system is  gone again.

depending on what you do, metros event-rate-jitter simply adds to more MIDI-and-other event-rate jitters all over this weird Max system(supercollider is, by default, more predictably tight on timing of everything, all around)... 
...i also don't think it should be necessary to have a VS smaller than 32(i prefer 64 or 128) for most things and i like that this allows me to leave 'overdrive' and 'in audio interrupt' off entirely...
...this same computer can then run a synchronized video-patch more easily this way as some of the CPU used for event-rate triggering can be saved for that part as well(though i do things in openGL, there's still some parameter-changes that come from metro-based clocks that are synchronized to the transport)...

so basically, the system i've created here for synchronizing a finger-drumming patch to a larger setup, where i'm not sure what i'm going to add later too, has been served best by planning it all out, right from the start, based on sample-accuracy(having added audio-recording recently in a certain way, i already found that having everything tied to a sample-accurate clock allowed for me to tie that in with minimal latency on the recording side as well).
the poly-voice number is used to trigger the voice by signal(as Peter described above), and this same number is stored in seq~ for the sequencer... here too, the sample-accuracy served me well by reducing the amount of timing-jitters possible all over the system :)

oh i wasnt really talking about your use case, more about that original question from 10 years back.

what could be a good reason to play drumsamples from a signal rate sequencer?

one which justifies the extra processing power and messy things like sending different signal triggers into different poly~ inputs?

yes, you can have bigger vs and leave overdrive off. what´s more?

Lol, Raja the resident ninja strikes again* :p (i saw the post earlier but couldn't respond). Awesome performance though but saying you "souped up" my patch is very generous because it's as barebones as i could get it. If we take that analogy further i'd say i had barely fixed the cooking utensils there...

The fluid-dynamics had me wondering how it would sound when notes are created if ripples collide though? Great performance nonetheless

*because of the edits ofcourse, they have not gone by unnoticed :) They usually make up for a fun read though as almost everything after the edit stops making sense

Honestly Roman, i don't actually know. I've just been brought up with the notion that UI is bad and control-message is bad so this is my gospel now...

And the problem with the inaccuracies is not the individual case but the build-up of each inaccuracy over time?

there are no buildups. the only inaccuracy which appears is when an event switches domains.

if someone uses shitty windows IO without ASIO while he is good at gen~, it might make sense to build signal rate sequencers.

for all other situations i dont see it. from my perspective it simply needs too much CPU as soon as you need to do more than click click boom.

and of course it only makes sense when you exclusively use max/msp.

as soon as you want to use javascript, trigger VST instruments, not to speak of outputting midi or network protocols, print something to a GUI, you have to go back to data rate anyway.

and as soon as you want to send complex numbers using your signal sequencer, you need to deal with mc- oder poly~.

one day we should do a collaborative "how do you do it" thread for sequencing events using all the different tools/domains/threads in max.

Dsp only gets expensive quick indeed. Some quick testing shows max is way more precise than i gave it credit for. While dsp is precise down to the sample there is some delay with Max-messages but it seems the inaccuracy itself remains consistent. 

stuff usually starts with the first sample of the next vector, so that at vs 32 incoming events will be quantized to a 0.7 ms grid, which is about what a physical midi connection does to a 3 byte message, too (the pure connection from controller to controller, that is.)

signal accuray is 16 or 32 times better, depending on what you do.

btw., has the original question from 2014 already been answered by any of us?

grafik.png

to turn the signal which goes to the thispoly~ back to zero is more complicated.

in most cases you might be fine with data rate accuracy though (like the flag which adsr~ or line~ provide.) it does not hurt if the voice is turned off a bit later.

signal accuray is 16 or 32 times better, depending on what you do.
 

btw., has the original question from 2014 already been answered by any of us?

starting a voice from a trigger is easy:

or wait... hm. no, you have to do it with signal accuray, too. :)

actually, if it is a sample player, you should create "note off" triggers on a parallel stream from outside the poly anyways.

"btw., has the original question from 2014 already been answered by any of us?"

"Triggering a [poly~] object with bang messages isn't sample accurate. I can't figure out how to trigger a [poly~] voice from a pulse signal."

Yes, my post from 12th of july tackled this. In~ 1 is just an integer counter at signal rate so it functions like a trigger and sets the index for poly-voice.

image.png

The question in question:
"Triggering a [poly~] object with bang messages isn't sample accurate. I can't figure out how to trigger a [poly~] voice from a pulse signal."

Yes, my post from 12th of july tackled this. In~ 1 is just an integer counter at signal rate so it functions like a trigger and sets the index for poly-voice. 

sorry for overlooking you. but this is a lot of stuff. what about making it shorter?

and did you notice that the data rate output of poly~ is not sample accurate? :)

you can do it without loop, and therefore without data rate.

the 1 sample delay which is required alternatively to the feedback loop approaches means that you can now send note events as fast as SR/4.


you can do it without loop, and therefore without data rate.

the 1 sample delay which is required alternatively to the feedback loop approaches means that you can now send note events as fast as SR/4.


This is what i came up with, if you feel it can be done shorter by all means go ahead...

i did yeah, hence the loadbang and sig~ after thispoly. :) It only captures the voice-number and doesn't output anything unless you bang it

This is what i came up with, if you feel it can be done shorter by all means go ahead... 

"and did you notice that the data rate output of poly~ is not sample accurate? :)"

"you can do it without loop, and therefore without data rate."

But how do you deal with voice-allocation now? Because that's done with a signal in my patch. And i'm just going to pretend i'm hallucinating the qmetro :p

lol, the qmetro is a leftover from what i tried there back in the days.

its purpose is to reset the accumulator, because that thing cannot run endlessly and is "full" after a while (earlier than after a 64 bit float maximum, that is)

unfortunately resetting it flips the flipflop state to 0, so you should only reset it when no notes are running.

somebody else posted another version based on phasor and modulo (or pong?) somewhere in the forums many years back but i cannot find it now.

voice allocation? to what? to poly~ voices?

ah yeah, that also unsolved "i need a signal [cycle]" problem, which once again requires code where a single sample routes itself. no idea.

as a quick workaround you could only compose monophonic music from now on.

no, seriously, just use different trigger sequencers for different trigger counts, or eventually different size of triggers. (1.0, 2.0, ....) then you can sort and route them later.

lol, the qmetro is a leftover from what i tried there back in the days.  

ah yeah, that also unsolved "i need a signal [cycle]" problem, which once again requires code where a single sample routes itself. no idea. 

How to trigger [poly~] object sample accurately?