Re: [PD] Array indexing for the wind and the birds
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 -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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,:). ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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: http://megalego.free.fr/pd/mediale-test-divx.avi ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Tue, 23 Oct 2007 10:44:09 -0400 (EDT) Mathieu Bouchard <[EMAIL PROTECTED]> 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 -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote: > On Tue, 23 Oct 2007 10:44:09 -0400 (EDT) > Mathieu Bouchard <[EMAIL PROTECTED]> 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__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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)." ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Ven Oct 26 1:26 , Roman Haefeli sent: >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. > there was a thread: slowly load patches/abs without dropout http://lists.puredata.info/pipermail/pd-list/2007-01/046107.html the attached patch reads and creates a patch slowly triggered by a metro. as far as i remember i didn't implemented a correct array-creation. eni slowlyopen.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Fri, 2007-10-26 at 10:13 +0200, Enrique Erne wrote: > > On Ven Oct 26 1:26 , Roman Haefeli sent: > > >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. > > > > there was a thread: slowly load patches/abs without dropout > > http://lists.puredata.info/pipermail/pd-list/2007-01/046107.html > > the attached patch reads and creates a patch slowly triggered by a metro. as > far > as i remember i didn't implemented a correct array-creation. > > eni didn't that thread end with the conclusion, that a) it is very hard to do that in pd, since message to canvasses are different from the lines in the pd-file? b) this is something that should rather managed by pd itself and not in userspace? and still, if you do it in userspace, there is no way to tell beforehand, how many objects you can create in a certain amount of time without getting dropouts. that means, if you really want to avoid drop-outs, you would have to do it very slowly, probably so slowly, that it takes ages to recreate a whole netpd patch. if there'd be a way to create constantly as many objects so that pd is just on the edge of having a dropout, but doesn't, then it would _might_ be worth to do it in userspace. roman roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Fri, 26 Oct 2007, Enrique Erne wrote: there was a thread: slowly load patches/abs without dropout http://lists.puredata.info/pipermail/pd-list/2007-01/046107.html the attached patch reads and creates a patch slowly triggered by a metro. as far as i remember i didn't implemented a correct array-creation. So, why would that be more realtime-safe? I don't understand. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Oct 27, 2007, at 1:59 AM, Mathieu Bouchard wrote: > On Fri, 26 Oct 2007, Enrique Erne wrote: > >> there was a thread: slowly load patches/abs without dropout >> http://lists.puredata.info/pipermail/pd-list/2007-01/046107.html >> the attached patch reads and creates a patch slowly triggered by a >> metro. as far >> as i remember i didn't implemented a correct array-creation. > > So, why would that be more realtime-safe? I don't understand. > sorry, i didn't want to say that it is realtime safe. my test failed as you see when you continue to read the thread. i was just replying to : >> complete patches are created as single abstractions. >> i wouldn't know how to break that into smaller chunks. and i think it looks nice to see how the patch slowly builds up :-) eni ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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 Description: Binary data simon___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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: > > 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
Hallo, simon wise hat gesagt: // simon wise wrote: > 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? [r pd] | [route dsp] | 1/0 Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Sun, 2007-10-28 at 16:37 +0100, Frank Barknecht wrote: > Hallo, > simon wise hat gesagt: // simon wise wrote: > > > 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? > > [r pd] > | > [route dsp] > | > 1/0 exactly, but with that you can only track changes, you cannot request the actual state. that is why you need to do that in a patch, that is always open (as i mentioned in a previous mail), so that other patches can request the state from that patch. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Fri, 26 Oct 2007, Roman Haefeli wrote: a) it is very hard to do that in pd, since message to canvasses are different from the lines in the pd-file? No, they are not different. Lines in the pd-file are interpreted as message to a canvas using #X, a message to [canvasmaker] using #N, or a message to an array using #A. "#N canvas" and "#X restore" will change the receiver of the receive-symbol #X so that it points to the correct canvas at all time. They use pd_pushsym and pd_popsym, which maintain a list of receivers for each receive-symbol in which only the last element is a currently active receive-symbol. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
