So I was playing with the FFT example that lets you adjust the gain for frequency bands that gets applied to a plain noise signal. In messing around I found that I could actually make some cool sounds that seemed like rushes of wind and birds and animals chirping. So, that's the goal. I want to make a birds and wind patch based on the resynthesis.pd audio example. I thought for starters I would use some [metro]s connected to [random]s that would send numbers down to [line] objects, which would generate lines to write into my gain array. Does this sound like a reasonable strategy?
My real question is how to work with arrays in this manner. I'd like to use [line] objects to generate small sequences that I write into short segments of an array. With a for loop this would be straight forward, but I don't know how to iterate through an array, or how to generate the line instantaneously rather than having it take some amount of time like you normally would use line for an envelope or something.
In the long run I'll need to remember the start index and length of each "chirp" so that after a short delay I can turn the gain back down at that location. Anything like a priority queue in PD, so I can just have my delay's pop off the queue? Also, how tough is it to dynamically create objects from within patches? Say, if I make a self contained chirp patch that deals with it's own cleanup, can I sort of instantiate it with some parameters and then send it off to do it's thing and die when it's done? (Was just reading the papers on Chuck, so maybe my mind is thinking in the wrong way for PD...)
Well, hopefully at least my goal is clear :-)
Thanks for the help, Jeff
Hallo, Jeff Rose hat gesagt: // Jeff Rose wrote:
So I was playing with the FFT example that lets you adjust the gain for frequency bands that gets applied to a plain noise signal. In messing around I found that I could actually make some cool sounds that seemed like rushes of wind and birds and animals chirping. So, that's the goal. I want to make a birds and wind patch based on the resynthesis.pd audio example. I thought for starters I would use some [metro]s connected to [random]s that would send numbers down to [line] objects, which would generate lines to write into my gain array. Does this sound like a reasonable strategy?
Generally a lot of things are resonable strategies. ;) I'm not sure that I've understood what you want to do, though. At http://footils.org/cms/show/60 there is a spectral delay patch, that maybe can be useful to look at, as it also uses a changing array to control gain (and feedback and delay) of FFTs. It also includes a way to control the array(s) algorithmically.
My real question is how to work with arrays in this manner. I'd like to use [line] objects to generate small sequences that I write into short segments of an array. With a for loop this would be straight forward, but I don't know how to iterate through an array, or how to generate the line instantaneously rather than having it take some amount of time like you normally would use line for an envelope or something.
First you start with a counter [f ]x[+ 1] that you reset to 0 on every go and then bang from an [until], which gets started by a number instead of a bang. [until] then will bang that many times and thus make the counter count from 0 to arraysize.
With that counter you drive two things: a) an expr-object which holds the function that you want to write to the array, like [expr 0.5
- $f1 - 0.2] or so. Normalize the counter as needed and change
parameters of expr as well. Then b) you use the counter value as index into the array (second inlet of [tabwrite]). Use proper triggering with [t a a] to first set the index, then calculate the expr.
This general technique can be varied with random objects and what not. Maybe writing noise with random is a good way to get familiar with it. It also is used in the examples a lot, e.g. to write hann-curves or bell-curves in the paf examples (F12, F13).
In the long run I'll need to remember the start index and length of each "chirp" so that after a short delay I can turn the gain back down at that location. Anything like a priority queue in PD, so I can just have my delay's pop off the queue?
Take a look at qlist, textfile, pipe or list-fifo, list-lifo from the [list]-abs abstractions collection.
Also, how tough is it to dynamically create objects from within patches? Say, if I make a self contained chirp patch that deals with it's own cleanup, can I sort of instantiate it with some parameters and then send it off to do it's thing and die when it's done? (Was just reading the papers on Chuck, so maybe my mind is thinking in the wrong way for PD...)
This is not the ideal way of thinking in Pd/Max. For polyphony in Pd instead you should create all needed objects in advance and possibly switch~ them off when they are not needed to save CPU. Dynamically creating objects should only be done on startup of a patch, not while it's running.
Ciao
Frank Barknecht _ ______footils.org__
Whoah, great! Thanks a lot for the tips Frank and Jamie. footils.org looks like a treasure trove of interesting stuff to learn from. I think with this info I can put together the wind and birds patch.
I'd kind of like to dig a little more into the dynamic patch question though. It seems like a pretty fundamental design decision or constraint to not handle dynamic creation and deletion of objects within the synthesis engine. Is this just not an easy thing to do in a visual programming environment, or are there architectural reasons? In NetPD, which is incredibly fun, there are number of things you can do dynamically, like load instruments and effects, generate new rhythm sequences etc. I thought this seemed like a pretty nice way to do things, although I haven't looked into it yet to see if it requires some special extensions or something. Anyways, it would be great to hear what experienced people have to say about dynamicity in PD.
Vielen Dank für die Hilfe, Jeff
Frank Barknecht wrote:
Hallo, Jeff Rose hat gesagt: // Jeff Rose wrote:
So I was playing with the FFT example that lets you adjust the gain for frequency bands that gets applied to a plain noise signal. In messing around I found that I could actually make some cool sounds that seemed like rushes of wind and birds and animals chirping. So, that's the goal. I want to make a birds and wind patch based on the resynthesis.pd audio example. I thought for starters I would use some [metro]s connected to [random]s that would send numbers down to [line] objects, which would generate lines to write into my gain array. Does this sound like a reasonable strategy?
Generally a lot of things are resonable strategies. ;) I'm not sure that I've understood what you want to do, though. At http://footils.org/cms/show/60 there is a spectral delay patch, that maybe can be useful to look at, as it also uses a changing array to control gain (and feedback and delay) of FFTs. It also includes a way to control the array(s) algorithmically.
My real question is how to work with arrays in this manner. I'd like to use [line] objects to generate small sequences that I write into short segments of an array. With a for loop this would be straight forward, but I don't know how to iterate through an array, or how to generate the line instantaneously rather than having it take some amount of time like you normally would use line for an envelope or something.
First you start with a counter [f ]x[+ 1] that you reset to 0 on every go and then bang from an [until], which gets started by a number instead of a bang. [until] then will bang that many times and thus make the counter count from 0 to arraysize.
With that counter you drive two things: a) an expr-object which holds the function that you want to write to the array, like [expr 0.5
- $f1 - 0.2] or so. Normalize the counter as needed and change
parameters of expr as well. Then b) you use the counter value as index into the array (second inlet of [tabwrite]). Use proper triggering with [t a a] to first set the index, then calculate the expr.
This general technique can be varied with random objects and what not. Maybe writing noise with random is a good way to get familiar with it. It also is used in the examples a lot, e.g. to write hann-curves or bell-curves in the paf examples (F12, F13).
In the long run I'll need to remember the start index and length of each "chirp" so that after a short delay I can turn the gain back down at that location. Anything like a priority queue in PD, so I can just have my delay's pop off the queue?
Take a look at qlist, textfile, pipe or list-fifo, list-lifo from the [list]-abs abstractions collection.
Also, how tough is it to dynamically create objects from within patches? Say, if I make a self contained chirp patch that deals with it's own cleanup, can I sort of instantiate it with some parameters and then send it off to do it's thing and die when it's done? (Was just reading the papers on Chuck, so maybe my mind is thinking in the wrong way for PD...)
This is not the ideal way of thinking in Pd/Max. For polyphony in Pd instead you should create all needed objects in advance and possibly switch~ them off when they are not needed to save CPU. Dynamically creating objects should only be done on startup of a patch, not while it's running.
Ciao
Hallo, Jeff Rose hat gesagt: // Jeff Rose wrote:
I'd kind of like to dig a little more into the dynamic patch question though. It seems like a pretty fundamental design decision or constraint to not handle dynamic creation and deletion of objects within the synthesis engine.
Well, yes, it was a pretty fundamental decision. Languages like SuperCollider, Nova and Csound to some extent show, that dynamically creating synthesis objects can work in a realtime system as well. But with Pd, you indeed have to be careful what you do and first look into different approaches to solve your problem. There are some ways around it like write externals that can manage voices dynamically e.g. using flext and SndObj. But anyway even when you have to create all needed voices in advance, you already can do pretty big things in Pd.
Ciao
Frank Barknecht _ ______footils.org__
Hi! Frank Barknecht a écrit :
Hallo, Jeff Rose hat gesagt: // Jeff Rose wrote:
I'd kind of like to dig a little more into the dynamic patch question though. It seems like a pretty fundamental design decision or constraint to not handle dynamic creation and deletion of objects within the synthesis engine.
Well, yes, it was a pretty fundamental decision. Languages like SuperCollider, Nova and Csound to some extent show, that dynamically creating synthesis objects can work in a realtime system as well. But with Pd, you indeed have to be careful what you do and first look into different approaches to solve your problem. There are some ways around it like write externals that can manage voices dynamically e.g. using flext and SndObj. But anyway even when you have to create all needed voices in advance, you already can do pretty big things in Pd.
Ciao
I've just made a video screenshot of the project I'm working on, just to have a look on what is possible to do with pd's dynamical patching, it's not about sound processing, but it might give some clues. Careful, the video is in a very bad quality, and my patches doesn't work fully.
Also, Jeff, your project about birds sounds very intersting, you certainly know the work of Olivier Messiaen,:).
Patrice Colet a écrit :
Hi! Frank Barknecht a écrit :
Hallo, Jeff Rose hat gesagt: // Jeff Rose wrote:
I'd kind of like to dig a little more into the dynamic patch question though. It seems like a pretty fundamental design decision or constraint to not handle dynamic creation and deletion of objects within the synthesis engine.
Well, yes, it was a pretty fundamental decision. Languages like SuperCollider, Nova and Csound to some extent show, that dynamically creating synthesis objects can work in a realtime system as well. But with Pd, you indeed have to be careful what you do and first look into different approaches to solve your problem. There are some ways around it like write externals that can manage voices dynamically e.g. using flext and SndObj. But anyway even when you have to create all needed voices in advance, you already can do pretty big things in Pd.
Ciao
I've just made a video screenshot of the project I'm working on, just to have a look on what is possible to do with pd's dynamical patching, it's not about sound processing, but it might give some clues. Careful, the video is in a very bad quality, and my patches doesn't work fully.
Also, Jeff, your project about birds sounds very intersting, you certainly know the work of Olivier Messiaen,:).
oops the video link:
On Tue, 23 Oct 2007, Patrice Colet wrote:
Also, Jeff, your project about birds sounds very intersting, you certainly know the work of Olivier Messiaen,:).
hmm? how does that compare to, say, the work of Roger Whittaker?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard a écrit :
On Tue, 23 Oct 2007, Patrice Colet wrote:
Also, Jeff, your project about birds sounds very intersting, you certainly know the work of Olivier Messiaen,:).
hmm? how does that compare to, say, the work of Roger Whittaker?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
http://www.musicaltimes.co.uk/archive/obits/199209messiaen.html
"Always a keen ornithologist, Messiaen now set about transcribing the songs in meticulous detail, going on expeditions at all hours of the day and night, and incorporating not only the birdsongs but the landscapes he encountered into the massive Catalogue d’Oiseaux (1956–58)."
On Tue, 23 Oct 2007 10:44:09 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 23 Oct 2007, Patrice Colet wrote:
Also, Jeff, your project about birds sounds very intersting, you certainly know the work of Olivier Messiaen,:).
hmm? how does that compare to, say, the work of Roger Whittaker?
Roger Whittaker beats Messiaens "secret recipes" because he actually looks like Colonel Sanders.
Whittaker++
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
On Tue, 23 Oct 2007 10:44:09 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 23 Oct 2007, Patrice Colet wrote:
Also, Jeff, your project about birds sounds very intersting, you certainly know the work of Olivier Messiaen,:).
hmm? how does that compare to, say, the work of Roger Whittaker?
Roger Whittaker beats Messiaens "secret recipes" because he actually looks like Colonel Sanders.
Whittaker++
Yeah, Whittaker rules. He even can sings in German without being able to speak German. Amazing!
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Well, yes, it was a pretty fundamental decision. Languages like SuperCollider, Nova and Csound to some extent show, that dynamically creating synthesis objects can work in a realtime system as well.
and not to forget http://chuck.cs.princeton.edu/ marius.
On Tue, 2007-10-23 at 13:40 -0400, marius schebella wrote:
Frank Barknecht wrote:
Well, yes, it was a pretty fundamental decision. Languages like SuperCollider, Nova and Csound to some extent show, that dynamically creating synthesis objects can work in a realtime system as well.
and not to forget http://chuck.cs.princeton.edu/ marius.
...and indeed [chuck~] !
http://www-static.cc.gatech.edu/ugrads/m/mjr/chuck~/
Jamie
On Tue, 2007-10-23 at 14:37 +0200, Jeff Rose wrote:
Whoah, great! Thanks a lot for the tips Frank and Jamie. footils.org looks like a treasure trove of interesting stuff to learn from. I think with this info I can put together the wind and birds patch.
I'd kind of like to dig a little more into the dynamic patch question though. It seems like a pretty fundamental design decision or constraint to not handle dynamic creation and deletion of objects within the synthesis engine. Is this just not an easy thing to do in a visual programming environment, or are there architectural reasons? In NetPD, which is incredibly fun, there are number of things you can do dynamically, like load instruments and effects, generate new rhythm sequences etc. I thought this seemed like a pretty nice way to do things, although I haven't looked into it yet to see if it requires some special extensions or something. Anyways, it would be great to hear what experienced people have to say about dynamicity in PD.
dynamic patching in pd is done by sending messages to canvasses (patches, subpatches or abstractions). you don't need any externals for dynamic patching.
though netpd uses dynamic patching a lot, it is actually not _that_ much recommended in pd. as frank pointed out, it seems that it is not officially supported by miller, which is probably also the reason, why it is not documented in the pd-docu (but i think it is documented in 'pd-msg' tutorial, that should be included in pd-extended). the main problem with dynamic patching is, that it is very likely, that it causes audio drop-outs. especially when creating ~-objects, the dsp graph needs to be recompiled, which requires some cpu power. another issue with dynamic patching is, that it is much easier to create objects, but it is not that easy to delete them again. if you want to connect and disconnect objects dynamically, then it is most probably going to be very painstaking. pd-objects don't have a unique identifier, but they are just counted by their creation order. when a certain objects is removed, all subsequently created objects change their address. because of this, most (all?) dynamic netpd-patches just do create abstractions into empty canvasses and most of the time they are just removed by sending a 'clear' message to the canvas in order to workaround all issues, that are introduced by dynamically connect and disconnect objects. this introduces unfortunately further implications. for instance, when you want to send an audio signal to a dynamically created abstraction and receive the resulting signal, the signal is delayed by one block, because, regarding the second [send~]/[receive~] pair, the [receive~] is created first. this is the case in mx, if you use aux-fx, since these are dynamically created. to sum it up: dynamic patching in pd is certainly doable, but has its implications.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
dynamic patching in pd is done by sending messages to canvasses (patches, subpatches or abstractions). you don't need any externals for dynamic patching.
but you _can_ use externals, too. [dyn] will give you the opportunity to create objects dynamically and also delete objects by id... marius.
On Tue, 23 Oct 2007, Roman Haefeli wrote:
the main problem with dynamic patching is, that it is very likely, that it causes audio drop-outs.
It wouldn't take much code to introduce something that can wrap dynamic patching in a way that prevents any DSP recompilation at the wrong moment.
E.g. If I have a patch that has 40 DSP objects, and then I instantiate an abstraction that has 10 dsp objects, 20 times, this recompiles DSP 20 times, taking a total of 10*(40+(10+10*20)/2) = 1450 dsp_add calls. If the dynamic creations dominate, the time increases quadratically, which is one kind of "gets bad quite quickly".
Bracketing a bunch of dynamic object creations with a dsp-disable / dsp-enable pair, you just recompile once at the end, in the above example totalling to 40+10*20 = 240 dsp_add calls, which is exactly the size of the dsp graph you have at the end.
Getting any better than linear time is somewhat harder, especially for pd, but linear is already much better than quadratic.
especially when creating ~-objects, the dsp graph needs to be recompiled, which requires some cpu power.
... uninterruptible cpu power.
but if patches don't expect the dsp to be updated immediately, the job could be spread over several logical time blocks.
Of course the first solution I mentioned is best applied first, and then only bother with the latter if you need more realtimeness.
pd-objects don't have a unique identifier, but they are just counted by their creation order. when a certain objects is removed, all subsequently created objects change their address.
It's not hard to add a method to the canvas class that will delete whichever range of indices of objects that you want from a patch.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 2007-10-25 at 16:22 -0400, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Roman Haefeli wrote:
the main problem with dynamic patching is, that it is very likely, that it causes audio drop-outs.
It wouldn't take much code to introduce something that can wrap dynamic patching in a way that prevents any DSP recompilation at the wrong moment.
E.g. If I have a patch that has 40 DSP objects, and then I instantiate an abstraction that has 10 dsp objects, 20 times, this recompiles DSP 20 times, taking a total of 10*(40+(10+10*20)/2) = 1450 dsp_add calls. If the dynamic creations dominate, the time increases quadratically, which is one kind of "gets bad quite quickly".
Bracketing a bunch of dynamic object creations with a dsp-disable / dsp-enable pair, you just recompile once at the end, in the above example totalling to 40+10*20 = 240 dsp_add calls, which is exactly the size of the dsp graph you have at the end.
that is what i do in netpd since last change. whenever a patch is loaded, it is not openen per message anymore but created dynamically as an abstraction. i found out, that it takes _much_ less time, if dsp is turned off before and turned on after creating it. this is probably the difference between what you describe as linear and quadratic increase.
Getting any better than linear time is somewhat harder, especially for pd, but linear is already much better than quadratic.
especially when creating ~-objects, the dsp graph needs to be recompiled, which requires some cpu power.
... uninterruptible cpu power.
but if patches don't expect the dsp to be updated immediately, the job could be spread over several logical time blocks.
don't know how to do that. there is no way in pd to tell how much behind schedule pd is with computing, or is there? anyway, in the case of netpd it wouldn't help anyway, since complete patches are created as single abstractions. i wouldn't know how to break that into smaller chunks.
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Fri, 26 Oct 2007, Roman Haefeli wrote:
that is what i do in netpd since last change. whenever a patch is loaded, it is not openen per message anymore but created dynamically as an abstraction. i found out, that it takes _much_ less time, if dsp is turned off before and turned on after creating it.
The problem with that is that there is no way to figure out beforehand that the dsp was on, so you can't know for sure that it wasn't meant to be off, and I usually have it off.
this is probably the difference between what you describe as linear and quadratic increase.
yes, but if you instantiate several abstractions and turn the dsp on/off between instantiations, you are still in quadratic time, albeit a much milder (faster) form thereof. I can show you the math next time I see you... with simple pictures.
but if patches don't expect the dsp to be updated immediately, the job could be spread over several logical time blocks.
don't know how to do that.
That's a much harder solution, that involves tricky modifications to pd/src/d_ugen.c. Much harder than a (clean version of) the first solution. I haven't really looked into it, so I can't really tell you whether it makes sense and exactly how hard it'd be.
there is no way in pd to tell how much behind schedule pd is with computing, or is there?
Yes, use [realtime] and [timer] and [-].
anyway, in the case of netpd it wouldn't help anyway, since complete patches are created as single abstractions. i wouldn't know how to break that into smaller chunks.
No, the backgrounding of the dsp recompilation is something that has to be written in C and that shouldn't affect your patches any further than ensuring that they're ok with a small logical-time delay whenever recompiling the dsp (turning the dsp on explicitly, could be exempted from that delay)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, 2007-10-26 at 19:35 -0400, Mathieu Bouchard wrote:
On Fri, 26 Oct 2007, Roman Haefeli wrote:
that is what i do in netpd since last change. whenever a patch is loaded, it is not openen per message anymore but created dynamically as an abstraction. i found out, that it takes _much_ less time, if dsp is turned off before and turned on after creating it.
The problem with that is that there is no way to figure out beforehand that the dsp was on, so you can't know for sure that it wasn't meant to be off, and I usually have it off.
true, but i found a way in netpd to come around this problem. every netpd session starts with chat, chat sets dsp to 1 and also chats stays open until the end of the session. it is not possible to request the actual dsp state, but it is possible to track all changes of state and this is what chat does. other netpd patches can just ask chat about the actual dsp state. so even if you turn dsp off, it won't get turned on by loading a netpd-patch.
there is no way in pd to tell how much behind schedule pd is with computing, or is there?
Yes, use [realtime] and [timer] and [-].
ah ok. interesting. with that you could construct a 'dynamic patcher' that just does NOT cause a drop-out, right?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sat, 27 Oct 2007, Roman Haefeli wrote:
there is no way in pd to tell how much behind schedule pd is with computing, or is there?
Yes, use [realtime] and [timer] and [-].
ah ok. interesting. with that you could construct a 'dynamic patcher' that just does NOT cause a drop-out, right?
No, because either the dsp is completely recompiled or it isn't. If you load gradually then you should hit the same quadratic time problem.
I said you'd need to modify d_ugen.c. This is because there is no way to start compiling and not finish it and resume it later, while keeping the old compilation running in the meanwhile.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Sat, 2007-10-27 at 02:12 -0400, Mathieu Bouchard wrote:
On Sat, 27 Oct 2007, Roman Haefeli wrote:
there is no way in pd to tell how much behind schedule pd is with computing, or is there?
Yes, use [realtime] and [timer] and [-].
ah ok. interesting. with that you could construct a 'dynamic patcher' that just does NOT cause a drop-out, right?
No, because either the dsp is completely recompiled or it isn't. If you load gradually then you should hit the same quadratic time problem.
I said you'd need to modify d_ugen.c. This is because there is no way to start compiling and not finish it and resume it later, while keeping the old compilation running in the meanwhile.
ah, yes. what you say sounds reasonable to me. but you needed to say it so that i can see it.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On 27 Oct 2007, at 9:35 AM, Mathieu Bouchard wrote:
The problem with that is that there is no way to figure out
beforehand that the dsp was on, so you can't know for sure that it
wasn't meant to be off, and I usually have it off.
I don't know how to use it, but the status of the 'compute audio'
checkbox in the pd window must be surely stored and could be
accessible somehow? and also the messages that get sent to change it?
simon
On 28 Oct 2007, at 8:37 PM, simon wise wrote:
On 27 Oct 2007, at 9:35 AM, Mathieu Bouchard wrote:
The problem with that is that there is no way to figure out beforehand that the dsp was on, so you can't know for sure that it wasn't meant to be off, and I usually have it off.
I don't know how to use it, but the status of the 'compute audio' checkbox in the pd window must be surely stored and could be accessible somehow? and also the messages that get sent to change it?
or without mucking around in the source try:
simon
On 28 Oct 2007, at 9:01 PM, simon wise wrote:
On 28 Oct 2007, at 8:37 PM, simon wise wrote:
On 27 Oct 2007, at 9:35 AM, Mathieu Bouchard wrote:
The problem with that is that there is no way to figure out beforehand that the dsp was on, so you can't know for sure that it wasn't meant to be off, and I usually have it off.
I don't know how to use it, but the status of the 'compute audio' checkbox in the pd window must be surely stored and could be accessible somehow? and also the messages that get sent to change
it?or without mucking around in the source try:
<DSP?.pd>
on second thoughts that is a bit clumsy, you need a small delay after
bang-ing before testing, there is probably a better combination of
objects to test if DSP is on.
simon
On Sun, 28 Oct 2007, simon wise wrote:
On 28 Oct 2007, at 8:37 PM, simon wise wrote:
On 27 Oct 2007, at 9:35 AM, Mathieu Bouchard wrote:
The problem with that is that there is no way to figure out beforehand that the dsp was on, so you can't know for sure that it wasn't meant to be off, and I usually have it off.
I don't know how to use it, but the status of the 'compute audio' checkbox in the pd window must be surely stored and could be accessible somehow? and also the messages that get sent to change it?
or without mucking around in the source try:
It doesn't detect when DSP gets turned off. This can be figured out using [r pd] [route dsp] though. What you have done is necessary in order to detect the initial dsp state (at the moment of loading a patch that needs to know the dsp state).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hi Jeff,
On Tue, 2007-10-23 at 14:37 +0200, Jeff Rose wrote: Anyways, it would be great to hear
what experienced people have to say about dynamicity in PD.
You might want to take a look at Thomas Grill's [dyn]
http://www.parasitaere-kapazitaeten.net/ext/dyn/
Although, I think if you fancy this route, you should probably check out the latest CVS version.
With regard to dynamicity in PD in general, I think if you want to do something like a polyphonic synth, then it would be better to statically allocate the voices than try to do it dynamically in PD. Either that, or use something like Csound (via [csoundapi~]) to do the synthesis.
Jamie
On Tue, 2007-10-23 at 01:00 +0200, Jeff Rose wrote:
My real question is how to work with arrays in this manner. I'd like to use [line] objects to generate small sequences that I write into short segments of an array. With a for loop this would be straight forward, but I don't know how to iterate through an array, or how to generate the line instantaneously rather than having it take some amount of time like you normally would use line for an envelope or something.
[until] is Pd's looping mechanism.
Anything like a priority queue in PD, so I can just have my delay's pop off the queue?
I think PDcontainer does this (http://grh.mur.at/software/pdcontainer.html)
Also, how tough is it to dynamically create objects from within patches?
If you have pd-extended there is some info under the documentation browswer under manuals/pd-msg/.
BUT, I don't think dynamic patching in Pd as it currently stands is officially supported (by Miller), and unexpected things can happen! That said, I generally haven't had too much trouble with it, YMMV.
Jamie
On Tue, 23 Oct 2007, Jamie Bullock wrote:
BUT, I don't think dynamic patching in Pd as it currently stands is officially supported (by Miller),
It's quite useless to say that, unless you are interested in the philosophical aspects of whether dynamic patching is a feature of pd, what is a feature, and the meaning of "official" and perhaps of "is". At least several commands of dynamic patching are so much used that Miller can't remove them, and if he did, then Hans would put them back anyway.
and unexpected things can happen!
What are you talking about?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, 2007-10-23 at 15:03 -0400, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Jamie Bullock wrote:
BUT, I don't think dynamic patching in Pd as it currently stands is officially supported (by Miller),
It's quite useless to say that, unless you are interested in the philosophical aspects of whether dynamic patching is a feature of pd, what is a feature, and the meaning of "official" and perhaps of "is". At least several commands of dynamic patching are so much used that Miller can't remove them, and if he did, then Hans would put them back anyway.
and unexpected things can happen!
What are you talking about?
http://lists.puredata.info/pipermail/pd-list/2007-09/053892.html
...unless you are interested in the philosophical aspects of whether crashing is a feature of pd, and the meaning of "unexpected" in the context of the following:
"init" is one of many messages that Pd and its gui send back and
forth, which
aren't intended to have any user-level functionality... of course, some of those messages like "connect" have proved useful at the user level; but none of them are guaranteed to do anything useful or even to be safe. The only one that's "supported" is "dsp" for turning audio computation on and off.
Jamie
On Wed, 24 Oct 2007, Jamie Bullock wrote:
http://lists.puredata.info/pipermail/pd-list/2007-09/053892.html
...unless you are interested in the philosophical aspects of whether crashing is a feature of pd, and the meaning of "unexpected" in the context of the following:
"init" is one of many messages that Pd and its gui send back and forth, which aren't intended to have any user-level functionality... of course, some of those messages like "connect" have proved useful at the user level; but none of them are guaranteed to do anything useful or even to be safe. The only one that's "supported" is "dsp" for turning audio computation on and off.
You can crash pd, or the equivalent thereof, banging a [until] without anything else. Now what? Yes, it would be better if neither [until] nor self-deletions would ever cause problems nor ever had gotchas, but both [until] and self-deletions are in use right now and people can learn how to ensure that they don't crash, and it didn't take *them* any guarantee from any authority, and not even an impression of foolproof safety, authority or not.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, Oct 23, 2007 at 03:03:22PM -0400, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Jamie Bullock wrote:
BUT, I don't think dynamic patching in Pd as it currently stands is officially supported (by Miller),
It's quite useless to say that, unless you are interested in the philosophical aspects of whether dynamic patching is a feature of pd, what is a feature, and the meaning of "official" and perhaps of "is". At least several commands of dynamic patching are so much used that Miller can't remove them, and if he did, then Hans would put them back anyway.
Incorrect; this statement is not at all useless for people who's primary Pd platform is Miller's version, on the contrary it's quite true, and of great concen.
Best,
Chris.
On Wed, 24 Oct 2007, Chris McCormick wrote:
On Tue, Oct 23, 2007 at 03:03:22PM -0400, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Jamie Bullock wrote:
BUT, I don't think dynamic patching in Pd as it currently stands is officially supported (by Miller),
It's quite useless to say that, unless you are interested in the philosophical aspects of whether dynamic patching is a feature of pd, what is a feature, and the meaning of "official" and perhaps of "is". At least several commands of dynamic patching are so much used that Miller can't remove them, and if he did, then Hans would put them back anyway.
Incorrect; this statement is not at all useless for people who's primary Pd platform is Miller's version, on the contrary it's quite true, and of great concen.
Oh yeah, it's of great concern. You'd have to download a diff that modifies Miller's pd so that it becomes as sane or insane as you want it to be, and then use /usr/bin/patch to modify Miller's source, unless someone provides a prepatched version of Miller's source that is not Hans'.
I strongly suspect that dynamic patching features won't change or be removed in Miller's pd anyway.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andy Farnell -
Chris McCormick -
Frank Barknecht -
Jamie Bullock -
Jeff Rose -
Jeff Rose -
marius schebella -
Mathieu Bouchard -
Patrice Colet -
Roman Haefeli -
simon wise