Hi
Can I expect $0 to always be the same in a given abstraction every time I load a patch?
The reason I ask, is I'd like to use $0 as an unique identifier together with sssad...
On Tue, 2008-07-22 at 22:37 +0200, Atte André Jensen wrote:
Hi
Can I expect $0 to always be the same in a given abstraction every time I load a patch?
The reason I ask, is I'd like to use $0 as an unique identifier together with sssad...
from my experience: yeah, if you open your patches in the exact same order, then all $0 are the same.
BUT: it is not documented anywhere, how $0 behaves in detail. it might be possible, that in a future versions of pd it starts counting from another value than 1000 (which is a pretty arbitrary decision anyway). DON'T rely on it. also i don't think, that it is a good idea to force yourself to open your patches always in the same order. your system will fail, as soon as you edit your patch only in the slightiest way. it is recommended to do your own counter, that only counts what really needs to be counted for your state saving.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
it is recommended to do your own counter, that only counts what really needs to be counted for your state saving.
Thanks for the advice, I'll take this route.
On Tue, Jul 22, 2008 at 10:37:44PM +0200, Atte André Jensen wrote:
The reason I ask, is I'd like to use $0 as an unique identifier together with sssad...
Is this so you can save and load different groups of pre-sets separately? I have been trying to think of a nice portable solution to that problem, using sssad. I have some ideas, but nothing concrete yet.
Best,
Chris.
Chris McCormick wrote:
Is this so you can save and load different groups of pre-sets separately? I have been trying to think of a nice portable solution to that problem, using sssad. I have some ideas, but nothing concrete yet.
No.
I have an abstraction that counts the beats (or 1/8 notes or other note values) and sends out 0, 1, 2, 3 etc for every beat. The idea is to instantiate this for every "instrument" that needs to know about time. So in one piece it might be two in others 50. A convienient way to store them was simply to refer to $0, since I didn't have to worry about making some unique identifier up for each instance.
Does it make sense?
On Wed, Jul 23, 2008 at 07:25:58AM +0200, Atte André Jensen wrote:
Chris McCormick wrote:
Is this so you can save and load different groups of pre-sets separately? I have been trying to think of a nice portable solution to that problem, using sssad. I have some ideas, but nothing concrete yet.
No.
I have an abstraction that counts the beats (or 1/8 notes or other note values) and sends out 0, 1, 2, 3 etc for every beat. The idea is to instantiate this for every "instrument" that needs to know about time. So in one piece it might be two in others 50. A convienient way to store them was simply to refer to $0, since I didn't have to worry about making some unique identifier up for each instance.
I understand. You want "throw-away" auto-ids. I'm not sure if anyone has come up with a satisfactory way of doing that, but I will have a think about it.
Incidentally, How I handle timing is I have a global timer [s-metro] that keeps going up and up, and I use [mod 4] to (for example) have a loop of 4 ticks or [mod 32] for 32 ticks. Sometimes I get crazy and add together two [mod]s to get some weird sounding rhythms.
Chris.
Chris McCormick wrote:
I understand. You want "throw-away" auto-ids. I'm not sure if anyone has come up with a satisfactory way of doing that, but I will have a think about it.
At least auto-ids. They shouldn't be thrown more away than they are the same next time :-)
Incidentally, How I handle timing is I have a global timer [s-metro] that keeps going up and up, and I use [mod 4] to (for example) have a loop of 4 ticks or [mod 32] for 32 ticks. Sometimes I get crazy and add together two [mod]s to get some weird sounding rhythms.
Sounds just like mine. Except I need the concept of "parts" (like in verse, chorus, etc). I've put some basic stuff together that allow me to specify 8 parts. Each part have a length, and a "goto"-part so when a part is done it goes to the next one. Besides this you can "request" a certain part to come up next. This is all reflected and controlled from my bcr.
What this means for my "ticker" is that it has on/off switches for each part, so a given ticker might only output if we're playing part 0 or 2.
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
I have an abstraction that counts the beats (or 1/8 notes or other note values) and sends out 0, 1, 2, 3 etc for every beat. The idea is to instantiate this for every "instrument" that needs to know about time. So in one piece it might be two in others 50. A convienient way to store them was simply to refer to $0, since I didn't have to worry about making some unique identifier up for each instance.
Does it make sense?
I don't yet understand: What exactly do you want to store?
Generally one should not assume anything about $0 except that it is a unique number in every .pd-file. Well, currently you can also assume that it starts at 1000 and will only grow but assuming anything else is bad and will break in the long run.
So for sssad: You can use keys like [sssad $0-somekey] but as soon as you save them to a file or message box, you will have something like 1026-somekey in your storage and you can only restore it if you're lucky because 1026 doesn't equal $0. 1026 even is a completely different concept than $0.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
I don't yet understand: What exactly do you want to store?
Such tickers would have gui-switches for which "parts" (like in structure) they're active in. That's what I'd like to store...
So for sssad: You can use keys like [sssad $0-somekey] but as soon as you save them to a file or message box, you will have something like 1026-somekey in your storage and you can only restore it if you're lucky because 1026 doesn't equal $0. 1026 even is a completely different concept than $0.
Right, I understand. I promise I'll refer from using $0 this way ever again :-)
Atte André Jensen schreef:
So for sssad: You can use keys like [sssad $0-somekey] but as soon as you save them to a file or message box, you will have something like 1026-somekey in your storage and you can only restore it if you're lucky because 1026 doesn't equal $0. 1026 even is a completely different concept than $0.
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...
from memory this is one of the reasons why i have yet to knuckle down and figure out sssad for my own stuff - my state saving system is current a piece of paper with pencil numbers scrawled all over it.
Damian Stewart wrote:
Atte André Jensen schreef:
So for sssad: You can use keys like [sssad $0-somekey] but as soon as you save them to a file or message box, you will have something like 1026-somekey in your storage and you can only restore it if you're lucky because 1026 doesn't equal $0. 1026 even is a completely different concept than $0.
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.
mfga.sdr IOhannes
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.
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
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__
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!
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 damian@frey.co.nz 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
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__
Damian Stewart wrote:
my state saving system is current a piece of paper with pencil numbers scrawled all over it.
I like paper, but I think sssad is cooler :-)
-
Atte André Jensen -
Chris McCormick -
Damian Stewart -
Frank Barknecht -
hard off -
IOhannes m zmoelnig -
Luke Iannini -
Roman Haefeli