hello friends,
what are your favorite objects for going from signals to events?
specifically, i'd like to make a sample accurate / audio-driven sequencer. I'm looking for something like max's "seq~" object, which outputs events when a phasor input in its inlet crosses various thresholds.
Any ideas?
-ali
- Ali Momeni batchku@gmail.com [2017-09-03 16:37]:
hello friends,
what are your favorite objects for going from signals to events?
specifically, i'd like to make a sample accurate / audio-driven sequencer. I'm looking for something like max's "seq~" object, which outputs events when a phasor input in its inlet crosses various thresholds.
Any ideas?
[max~] and [min~] perhaps.
[threshold~] is a useful object, although its syntax is a bit confusing. Cyclone's [edge~] is probably more reliable, if you don't mind using externals. ________________________________ From: Pd-list pd-list-bounces@lists.iem.at on behalf of Peter P. peterparker@fastmail.com Sent: 03 September 2017 15:47 To: pd-list@lists.iem.at Subject: Re: [PD] going from signals to events?
- Ali Momeni batchku@gmail.com [2017-09-03 16:37]:
hello friends,
what are your favorite objects for going from signals to events?
specifically, i'd like to make a sample accurate / audio-driven sequencer. I'm looking for something like max's "seq~" object, which outputs events when a phasor input in its inlet crosses various thresholds.
Any ideas?
[max~] and [min~] perhaps.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Ali,
On 2017-09-03 15:36, Ali Momeni wrote:
what are your favorite objects for going from signals to events?
specifically, i'd like to make a sample accurate / audio-driven sequencer.
Note that signal-to-event in Pd's architecture necessarily means the events occur up to 1 DSP block later than intended, and possibly not scheduled on Pd's logical clock (I haven't checked the source of eg [threshold~] to see if it schedules with constant 1-block latency vs variable as-soon-as-possible on the next block boundary latency, but I suspect the latter). So you'll get late events with up to 1.5ms jitter, with default settings.
If you want a sample-accurate audio-driven sequencer, you really need to keep everything in the signal domain. See for example the 0xA expr~ tutorials at https://archive.bleu255.com/0xA/
Claude
Thanks everyone, super helpful.
@peter: it seems to me that max~ and min~ take signals in and put
signals out. How would you use them to go from signal to event?
@liam: yes! threshold~ is what i was looking for; i'm always up for
doing the extra work to stick with vanilla.
@claude: deep. i'll look at the expr~ example, very helpful reference.
On Sun, Sep 3, 2017 at 11:27 AM, Claude Heiland-Allen claude@mathr.co.uk wrote:
Hi Ali,
On 2017-09-03 15:36, Ali Momeni wrote:
what are your favorite objects for going from signals to events?
specifically, i'd like to make a sample accurate / audio-driven sequencer.
Note that signal-to-event in Pd's architecture necessarily means the events occur up to 1 DSP block later than intended, and possibly not scheduled on Pd's logical clock (I haven't checked the source of eg [threshold~] to see if it schedules with constant 1-block latency vs variable as-soon-as-possible on the next block boundary latency, but I suspect the latter). So you'll get late events with up to 1.5ms jitter, with default settings.
If you want a sample-accurate audio-driven sequencer, you really need to keep everything in the signal domain. See for example the 0xA expr~ tutorials at https://archive.bleu255.com/0xA/
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
for what reason(s) do you feel the need to run a sequencer off an audio signal?
I'm very much willing to bet that all of them will end up being totally and easily do-able using message objects
I like having a single master clock that's a phasor~
I can imagine doing it all with events as well, bur curious in the performance difference.
do you have any experience with the comparison?
On Sun, Sep 3, 2017 at 12:04 PM, Matt Davey hard.off@gmail.com wrote:
for what reason(s) do you feel the need to run a sequencer off an audio signal?
I'm very much willing to bet that all of them will end up being totally and easily do-able using message objects
performance, as in CPU performance? For sure you're gonna get much greater performance using just messages.
It's also MUCH simpler to sequence with a [metro] and messages, and very easy to do interesting things to a sequence.
compare that to something like this, in the link claude just shared:
https://archive.bleu255.com/0xA/files/2016/04/010_shuffle.png
what a mess!
I see what you mean about having a single master clock, but why not just have a single master clock that's based on [metro] and a counter? You can use that clock to trigger sub-clocks to whatever resolution you like, right down to subsample accuracy.
Agreed on all fronts.
The reason i'm keen on having a master clock that's audio driven is because i also want to sync my step sequencer to looping audio buffers, playback with a phasor~
I see that this could also be done with with metro (i.e. trigger playback of the audio file)
On Sun, Sep 3, 2017 at 1:19 PM, Matt Davey hard.off@gmail.com wrote:
performance, as in CPU performance? For sure you're gonna get much greater performance using just messages.
It's also MUCH simpler to sequence with a [metro] and messages, and very easy to do interesting things to a sequence.
compare that to something like this, in the link claude just shared:
https://archive.bleu255.com/0xA/files/2016/04/010_shuffle.png
what a mess!
I see what you mean about having a single master clock, but why not just have a single master clock that's based on [metro] and a counter? You can use that clock to trigger sub-clocks to whatever resolution you like, right down to subsample accuracy.
exactly!
for any sort of sample playback, a [metro] and [vline~] approach is always going to be better than phasor~ based playback.
you're welcome to learn the hard way, and try to do it all using phasor~ though!
On Son, 2017-09-03 at 19:37 +0200, Matt Davey wrote:
exactly!
for any sort of sample playback, a [metro] and [vline~] approach is always going to be better than phasor~ based playback.
Except, if you aim for continuous (as in "at audio rate") pitch change which I wouldn't know how to do with message objects. I'd use a [phasor~] for that.
Roman
of course you can set continuous pitch change using ramps made with line~ or vline~ for ADSR style things,
but yeah, if you need FM on sample playback, then you will need a phasor~. But for that, you give up sample-accurate triggering, and will have to wait for block boundaries to trigger any phase changes.
Claude Heiland-Allen wrote:
If you want a sample-accurate audio-driven sequencer, you really need to keep everything in the signal domain. See for example the 0xA expr~ tutorials at https://archive.bleu255.com/0xA/
very interesting site indeed ! thanks for posting !
i downloaded the example patches and almost all of them use [expr floor] which throws the following error message:
========================================================== expr~ floor($v1*$v2 , 0) ... couldn't create expr: syntax error: function 'floor' needs 1 arguments ==========================================================
if i change [expr~ floor($v1*$v2 , 0)]
to
[expr~ floor($v1*$v2)] it is valid.
will this be the same thing ? has there been a syntax change with PD 0.48 ?
best
oliver
On 09/03/17 23:44, oliver wrote:
expr: syntax error: function 'floor' needs 1 arguments
iirc, there was a bugfix to floor() that finally removed the redundant 2nd argument, which had no purpose (and probably originated from a copy-n-paste coding error)
fgamsdr IOhannes
Eric Lyon's Lyonpotpourri library should be mentioned https://github.com/pd-projects/lyonpotpourri although seems like some code needs to be cleaned up, I'm getting segfaults with Pd-Extended and a custom Pd that uses a bit of Pd-extended code
He has many signal sequencing objects in the library though and it seems to work fairly well with vanilla, though it doesn't seem quite ready for 64-bit
-----Original Message----- From: Ali Momeni
hello friends,
what are your favorite objects for going from signals to events?
specifically, i'd like to make a sample accurate / audio-driven sequencer. I'm looking for something like max's "seq~" object, which outputs events when a phasor input in its inlet crosses various thresholds.
Any ideas?
-ali
_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 09/04/17 06:23, Seb Shader via Pd-list wrote:
though it doesn't seem quite ready for 64-bit
iirc, erik kind of refused getting his externals ready for 64bit archs (with 64bit pointers) until Pd would also use 64bit numbers (doubles)...
i obviously failed to explain the differences.
fgasmdr IOhannes
whoops, looks like he has actually been working on it, not sure why there's a separate repo.. https://github.com/ericlyon/lyonpotpourri3.0
-----Original Message----- From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list pd-list@lists.iem.at Sent: Mon, Sep 4, 2017 12:16 am Subject: Re: [PD] going from signals to events?
On 09/04/17 06:23, Seb Shader via Pd-list wrote:
though it doesn't seem quite ready for 64-bit
iirc, erik kind of refused getting his externals ready for 64bit archs (with 64bit pointers) until Pd would also use 64bit numbers (doubles)...
i obviously failed to explain the differences.
fgasmdr IOhannes
On 03/09/17 16:36, Ali Momeni wrote:
specifically, i'd like to make a sample accurate / audio-driven sequencer.
it should be possible to build something with bang~, tabreceive~ and looping through the 64 samples of a block to get the exact position where the phasor started in the previous block. with an additional delay of 1 block on the phasor it should be possible to sync the message-based sequencer to the audio (sample accurate). that would still not allow frequency-modulatiuon of the sequencer though...
-
Ali Momeni -
Claude Heiland-Allen -
IOhannes m zmoelnig -
Liam Goodacre -
martin brinkmann -
Matt Davey -
oliver -
Peter P. -
Roman Haefeli -
sebfumaster＠aol.com