Re: [PD] sssad key-name in abstractions (was: is $0 the same on every load?)
IOhannes m zmoelnig schreef: hmm.. so what if i have for example a delay abstraction which a GOP gui, and i want to have multiple instances of this abstraction? i suppose i'd have to name each one individually, passing a name on initialisation? what if i have a delay abstraction inside a synth abstraction, and i want two instances of the synth abstraction? then i have two instances of the delay abstraction but no easy way to name them without messily chaining up the name strings... hmm, the subject suggests this is about $0, so i am not sure whether i fully understand your question (or what you are missing): just use $0-mydel. that $0 is not 1026 shouldn't be a problem for you either. have changed the subject line to something better ;-) my understanding of sssad is that it requires data be given unique key names. the question is how to generate these unique key names within multiple instances of abstractions. the original discussion was about using $0 to do this, which doesn't seem possible. in your example if i save a bunch of states with eg mydelay-$0-delaytime when $0 is 1026, then go and try to load these up some other time, then $0 is not guaranteed to be 1026. i suppose the solution is to have a delay that takes an instance name argument, eg [mydelay left], then use that instance name in the sssad key, eg mydelay-$1-delaytime, which will create mydelay-left-delaytime for [mydelay left]. but then the problem remains - if i have a synth that has built-in delay [mydelay left], and i want to have two abstractions of this synth, i'm going to end up with two sets of keys mydelay-left-delaytime. so i need some kind of chained name thing, eg [mysynth squelchy] instantiates [mysynth $1-left], so the sssad key will be mydelay-squelchy-left-delaytime. chaining through multiple levels of abstraction like this (which i tend to do when i'm building patches) is going to lead to keynames like mylpf-squelchy-left-sawtooth-lfo-pre-cutoff, for the cutoff frequency of an lfo pre-filter inside the sawtooth generator for the left channel of the 'squelchy' synth. which i suppose isn't a problem, really, it's just a bit messy. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad key-name in abstractions
Damian Stewart wrote: i suppose the solution is to have a delay that takes an instance name argument, eg [mydelay left], then use that instance name in the sssad key, eg mydelay-$1-delaytime, which will create mydelay-left-delaytime for [mydelay left]. but then the problem remains - if i have a synth that has built-in delay [mydelay left], and i want to have two abstractions of this synth, i'm going to end up with two sets of keys mydelay-left-delaytime. so i need some kind of chained name thing, eg [mysynth squelchy] instantiates [mysynth $1-left], so the sssad key will be mydelay-squelchy-left-delaytime. the solution is to do it as it is done everywhere else: e.g. namepart of URIs: lists.puredata.info e.g. OSC-addresses: /squelchy/left/time chaining through multiple levels of abstraction like this (which i tend to do when i'm building patches) is going to lead to keynames like mylpf-squelchy-left-sawtooth-lfo-pre-cutoff, for the cutoff frequency of an lfo pre-filter inside the sawtooth generator for the left channel of the 'squelchy' synth. which i suppose isn't a problem, really, it's just a bit messy. once you've got used to namespaces it is not messy any more. at least i prefer setting-files that look like: /squelchy/left/time 10 /squelchy/right/time 20 /squeezy/left/time 20 rather than: 1023-deltime 10 1078-deltime 20 1123-deltime 20 but yes, you have to take care of that yourself. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad key-name in abstractions
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: Damian Stewart wrote: i suppose the solution is to have a delay that takes an instance name argument, eg [mydelay left], then use that instance name in the sssad key, eg mydelay-$1-delaytime, which will create mydelay-left-delaytime for [mydelay left]. but then the problem remains - if i have a synth that has built-in delay [mydelay left], and i want to have two abstractions of this synth, i'm going to end up with two sets of keys mydelay-left-delaytime. so i need some kind of chained name thing, eg [mysynth squelchy] instantiates [mysynth $1-left], so the sssad key will be mydelay-squelchy-left-delaytime. the solution is to do it as it is done everywhere else: e.g. namepart of URIs: lists.puredata.info e.g. OSC-addresses: /squelchy/left/time chaining through multiple levels of abstraction like this (which i tend to do when i'm building patches) is going to lead to keynames like mylpf-squelchy-left-sawtooth-lfo-pre-cutoff, for the cutoff frequency of an lfo pre-filter inside the sawtooth generator for the left channel of the 'squelchy' synth. which i suppose isn't a problem, really, it's just a bit messy. once you've got used to namespaces it is not messy any more. at least i prefer setting-files that look like: /squelchy/left/time 10 /squelchy/right/time 20 /squeezy/left/time 20 And with [sssad] the usual practice is to use an additional $1 inside of abstractions as prefix to [sssad] objects. Say you have a synth.pd patch intended to be uses with different settings. Inside of synth.pd you use these: [sssad $1/left/time] [sssad $1/right/time] Then you can use several different synths like this: [synth /bass] [synth /plingy] [synth /drum] etc. Your sssad-savefile will then look like this: /bass/left/time 12 /bass/right/time 28 /plingy/left/time 2137 /plingy/right/time 17 /drum/left/time 56 /drum/right/time 283 sssad-example.pd contains an example which uses sssliders.pd in this fashion. OTOH you can also deliberatly give many [synth]s the same name, if they should share their settings, for example to make a polyphonic synth with 12 copies of the same synth voice. Just make enough [synth /shared] abstractions and control them with [poly] (or use [polypoly]) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad key-name in abstractions
OTOH you can also deliberatly give many [synth]s the same name, if they should share their settings, for example to make a polyphonic synth with 12 copies of the same synth voice. Just make enough [synth /shared] abstractions and control them with [poly] (or use [polypoly]) wow, never thought of that. of course! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad key-name in abstractions (was: is $0 the same on every load?)
Yo, it's not as messy if you do it more hierarchically - I have a deeply nested set of abstractions that make up my composition kit, and I've tackled it like this: [suite /suite1] [suite /suite2] ... etc inside: [oscillator $1 /osc1] [oscillator $1 /osc2] etc. then you can do [sssad $1$2/frequency] [sssad $1$2/modulation] etc. inside that. (and of course you can continue this to any level, so inside [oscillator] you could have [sawtooth $1 $2 /saw1] and inside that [sssad $1$2$3/phase]) And, this ends up just being OSC essentially so that works out great if you are interested in communicating with your system remotely (which I do, using Memento). Cheers Luke On Wed, Jul 23, 2008 at 1:38 AM, Damian Stewart [EMAIL PROTECTED] wrote: IOhannes m zmoelnig schreef: hmm.. so what if i have for example a delay abstraction which a GOP gui, and i want to have multiple instances of this abstraction? i suppose i'd have to name each one individually, passing a name on initialisation? what if i have a delay abstraction inside a synth abstraction, and i want two instances of the synth abstraction? then i have two instances of the delay abstraction but no easy way to name them without messily chaining up the name strings... hmm, the subject suggests this is about $0, so i am not sure whether i fully understand your question (or what you are missing): just use $0-mydel. that $0 is not 1026 shouldn't be a problem for you either. have changed the subject line to something better ;-) my understanding of sssad is that it requires data be given unique key names. the question is how to generate these unique key names within multiple instances of abstractions. the original discussion was about using $0 to do this, which doesn't seem possible. in your example if i save a bunch of states with eg mydelay-$0-delaytime when $0 is 1026, then go and try to load these up some other time, then $0 is not guaranteed to be 1026. i suppose the solution is to have a delay that takes an instance name argument, eg [mydelay left], then use that instance name in the sssad key, eg mydelay-$1-delaytime, which will create mydelay-left-delaytime for [mydelay left]. but then the problem remains - if i have a synth that has built-in delay [mydelay left], and i want to have two abstractions of this synth, i'm going to end up with two sets of keys mydelay-left-delaytime. so i need some kind of chained name thing, eg [mysynth squelchy] instantiates [mysynth $1-left], so the sssad key will be mydelay-squelchy-left-delaytime. chaining through multiple levels of abstraction like this (which i tend to do when i'm building patches) is going to lead to keynames like mylpf-squelchy-left-sawtooth-lfo-pre-cutoff, for the cutoff frequency of an lfo pre-filter inside the sawtooth generator for the left channel of the 'squelchy' synth. which i suppose isn't a problem, really, it's just a bit messy. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad key-name in abstractions (was: is $0 the same on every load?)
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote: (and of course you can continue this to any level, so inside [oscillator] you could have [sawtooth $1 $2 /saw1] and inside that [sssad $1$2$3/phase]) I usually use it in this style: [oscillator /osc1] - [sawtooth $1/saw1] - [sssad $1/phase] to auto-create a [sssad /osc1/saw1/phase] in the end. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
