Hi list,
I have a patch that features the same abstraction many times. Each one of these abstractions are connected to different objects so they do other things each.
Now, trying to intergrade a snapshot feature to my patch, using the [sssad] object, I came to a problem with the abstractions: I opened each one within the patch and added the [aaasd xxx] object. When I save them all the same abstractions had the [aaasd xxx] object, which made my state load difficult (all the abstraction's setting are the same).
Can pd load each abstractions the object oriented way? Each abstraction to have it's set of properties?
If not, do I have to set for each of my abstraction outlets for their settings?
Thanks
Tasos
ΓñçóéìïðïéΓ₯ΓΓ΄Γ₯ Yahoo! ΓÑñΓ₯Γ¨ΓΓͺÑôΓ₯ ôÑ Γ₯Γï÷ëçôéΓͺà ìçΓΓ½ ìÑôÑ (spam); ΓΓ― Yahoo! Mail ÀéÑèΓΓ΄Γ₯Γ© ôçà ΓͺÑëýôΓ₯Γ±Γ§ ÀáΓÑôà ðñïóôÑóΓΓ‘ ΓͺÑôà ôùà Γ₯Γï÷ëçôéΓͺþà ìçΓáìΓôùà http://login.yahoo.com/config/mail?.intl=gr
Hallo, Tas Pas hat gesagt: // Tas Pas wrote:
I have a patch that features the same abstraction many times. Each one of these abstractions are connected to different objects so they do other things each.
Now, trying to intergrade a snapshot feature to my patch, using the [sssad] object, I came to a problem with the abstractions: I opened each one within the patch and added the [aaasd xxx] object. When I save them all the same abstractions had the [aaasd xxx] object, which made my state load difficult (all the abstraction's setting are the same).
Can pd load each abstractions the object oriented way? Each abstraction to have it's set of properties?
The trick here is to teach Pd to handle each use of an abstraction differently by "tagging" it with a different name. I do this with the first argument to the abstraction, and then, inside of that abstraction use [sssad $1/xxxx] instead of just [sssad xxxx].
So your abstraction "myabs.pd" has this inside:
[sssad $1/something]
and in the main patch you use [myabs] like this:
[myabs one] [myabs two] [myabs third]
or similar.
Then the sssad-values stored will be named like this: "one/something", "two/something" and "third/something" if you save the settings.
$0 would do something like this automatically, but you cannot use [sssad $0/something] in real life because if you save it to a file, what gets saved is something like "1004/something" but the "1004"-part will be different everytime you reopen the patch. So you have to use explicit names as recommended above.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, Aug 08, 2006 at 12:41:27PM +0200, Frank Barknecht wrote:
Hallo, Tas Pas hat gesagt: // Tas Pas wrote:
I have a patch that features the same abstraction many times. Each one of these abstractions are connected to different objects so they do other things each.
$0 would do something like this automatically, but you cannot use [sssad $0/something] in real life because if you save it to a file, what gets saved is something like "1004/something" but the "1004"-part will be different everytime you reopen the patch. So you have to use explicit names as recommended above.
And as such it would be very cool if there was something like $0 which gave you a consistent value between saves/loads and shutdowns of Pd. It would help with datastructures based saving too, and would do away with the entire need to name every single abstraction on your canvas just because you want to be able to save them.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Wed, 9 Aug 2006, Chris McCormick wrote:
And as such it would be very cool if there was something like $0 which gave you a consistent value between saves/loads and shutdowns of Pd. It would help with datastructures based saving too, and would do away with the entire need to name every single abstraction on your canvas just because you want to be able to save them.
Thats a good idea.
One could generate the ID automatically based on the name of the abstraction, its position (relative to the other abstraction with the same name) and the ID of the parent patch.
This way it might be possible to come up with unique ID's without having to name your abstractions individually.
e.g
MAIN1/abs4/subabs3
would be the 3rd abstraction "subabs" (ordered with increasing x then y) in the 4th abstraction "abs" in the main patch "MAIN".
Günter
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, geiger hat gesagt: // geiger wrote:
One could generate the ID automatically based on the name of the abstraction, its position (relative to the other abstraction with the same name) and the ID of the parent patch.
This way it might be possible to come up with unique ID's without having to name your abstractions individually.
e.g
MAIN1/abs4/subabs3
would be the 3rd abstraction "subabs" (ordered with increasing x then y) in the 4th abstraction "abs" in the main patch "MAIN".
I thought of that as well, but how do you deal with edits of a patch? Say you delete or recreate an abstraction instance, how should Pd know which abstraction is used for which saved data? Maybe Ben Bogart can say something about how he did it in picelTANGO, where auto-generated "tags" are in use as far as I understand.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 9 Aug 2006, Frank Barknecht wrote:
I thought of that as well, but how do you deal with edits of a patch? Say you delete or recreate an abstraction instance, how should Pd know which abstraction is used for which saved data? Maybe Ben Bogart can say something about how he did it in picelTANGO, where auto-generated "tags" are in use as far as I understand.
I think the person who edits the patch (the "programmer") should be aware of this, he should know that the settings for the first abstraction go into the abstraction that is on the left, just as he knows that the inlet/outlet that is on the left will be the first one.
Of course if you add an abstraction, there won't be any data for it to load. Also, if you add the abstraction at the beginning, the whole data will be shifted one abstraction.
If you remove one abstraction at the end, nothing happens, if you remove it somewhere in the middle, the data will get loaded differently.
Anyhow, not too different from adding and removing inlets and outlets. I don't see a real problem with that approach, but maybe there's more ?
Günter
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, geiger hat gesagt: // geiger wrote:
I think the person who edits the patch (the "programmer") should be aware of this, he should know that the settings for the first abstraction go into the abstraction that is on the left, just as he knows that the inlet/outlet that is on the left will be the first one.
Of course if you add an abstraction, there won't be any data for it to load.
Yes, that's no problem. Btw: With "$1-tags" it also is possible to use the same tag for different instances of an abstraction so that they share the same settings which is very useful for dealing with polyphony.
Also, if you add the abstraction at the beginning, the whole data will be shifted one abstraction.
Urgh ... ;)
If you remove one abstraction at the end, nothing happens, if you remove it somewhere in the middle, the data will get loaded differently.
Urgh++ ;) ;)
Anyhow, not too different from adding and removing inlets and outlets.
inlets and outlets are the only thing in Pd where position really matters (ignoring internals like connections for now), and that's already a little problem, although we got used to it. But you may remember proposals by Matju IIRC to introduce inlet arguments to specify which inlet should be at which position. I think, that was an idea carried over from jMax.
Anyways I generally prefer the explicit approach Pd uses most of the time. Two patches that print the same should also behave the same and that isn't the case anymore if we rely on position alone to load data.
How did [state] handle this?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, Aug 09, 2006 at 10:50:35AM +0200, Frank Barknecht wrote:
Hallo, geiger hat gesagt: // geiger wrote:
I think the person who edits the patch (the "programmer") should be aware of this, he should know that the settings for the first abstraction go into the abstraction that is on the left, just as he knows that the inlet/outlet that is on the left will be the first one.
Urgh ... ;)
Urgh++ ;) ;)
Anyhow, not too different from adding and removing inlets and outlets.
I'm with Frank on this one; I think it's pretty non-intuitive that if you add or remove abstractions, or even move them around your canvas the save data of other abstractions is suddenly lost/trasnposed to a different abstraction. That would confuse the heck out of artists and instrument builders and just plain annoy programmers, in my opinion. The only real solution I can see is a $0 type of argument that is generated when a new abstraction is instantiated and saved with the abstraction so that next time it gets loaded it has the same ID. Being slightly frightened of Pd's sources I have no idea how much work this would be though, or even if Miller would be interested in a patch to introduce this new identifier.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Wed, 9 Aug 2006, Chris McCormick wrote:
I'm with Frank on this one; I think it's pretty non-intuitive that if you add or remove abstractions, or even move them around your canvas the save data of other abstractions is suddenly lost/trasnposed to a different abstraction. That would confuse the heck out of artists and instrument builders and just plain annoy programmers, in my opinion.
Most of the time, if you have several abstractions of the same type in a patch, they do the same thing, so nothing is lost. If your patch only has one abstraction of each type, there is no problem anyhow.
The only real solution I can see is a $0 type of argument that is generated when a new abstraction is instantiated and saved with the abstraction so that next time it gets loaded it has the same ID. Being slightly frightened of Pd's sources I have no idea how much work this would be though, or even if Miller would be interested in a patch to introduce this new identifier.
Hmm, I see, seems that we are talking about different problems here. There is only one file where the abstraction is stored (lets say abs.pd). Now you have a patch with 5 "abs", every single one with a different ID but just one file (the abs.pd) to save them too.
ok, you could say that you save them all to the single file (ugly but possible), but then how do you know which id corresponds to which abstraction in the patch.
The only way you can distinguish these 5 abstractions in a patch is by their position and the way they are connected to other objects. Or, by naming them, which is what we currently do.
Günter
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Aug 09, 2006 at 02:14:36PM +0200, geiger wrote:
On Wed, 9 Aug 2006, Chris McCormick wrote:
Most of the time, if you have several abstractions of the same type in a patch, they do the same thing, so nothing is lost. If your patch only has one abstraction of each type, there is no problem anyhow.
For me that is not the case. For example, I might use my GOP datastructure envelope abstraction for several different things in one patch. I may use it to control the filter cutoff of something in one part of the patch, and somewhere else use it to control the volume of something. Now let's say I move the entire volume-controlling aparatus to a different part of the canvas, and then click the "load" bang in the [sssad/panel] state saving abstraction by Frank. Intuition says that the envelope should load the same data it has had all along, but with the method you proposed it would load some other data corresponding to this different location in the patch, maybe even the data of the cutoff-controlling envelope, which would be all wrong, or no data at all, which would just be irritating since your lovely hand crafted envelope would be gone forever.
The only real solution I can see is a $0 type of argument that is generated when a new abstraction is instantiated and saved with the abstraction so that next time it gets loaded it has the same ID. Being slightly frightened of Pd's sources I have no idea how much work this would be though, or even if Miller would be interested in a patch to introduce this new identifier.
Hmm, I see, seems that we are talking about different problems here. There is only one file where the abstraction is stored (lets say abs.pd). Now you have a patch with 5 "abs", every single one with a different ID but just one file (the abs.pd) to save them too.
ok, you could say that you save them all to the single file (ugly but possible), but then how do you know which id corresponds to which abstraction in the patch.
I don't mean to save the IDs into the abs.pd file. I mean to save them in the parent patch with the line which signals the creation of a new abs.pd(.) So something like this:
After the instantiation line: #X obj 24 583 abs my abs arguments; #I 54322345; ^^^ This is the unique ID generated by Pd.
Or even breaking backwards compatability: #X obj 24 583 54322345 abs my abs arguments; ^^^ This is the unique ID generated by Pd.
The only way you can distinguish these 5 abstractions in a patch is by their position and the way they are connected to other objects. Or, by naming them, which is what we currently do.
I think there is a fourth way as I have indicated above; to associate some Pd generated ID with each abstraction instantiation in the parent patch. Nobody has to use this ID, but it's there if you want something more permanent than $0. It would make it easier for unnamed things to be saved by memento or sssad or state.
Then there is another can of worms; generating IDs unique across several patches put together at different times. Hmmm. Maybe the ID could be the unix timestamp + milliseconds at the time when the abstraction was first instantitated?
All of this is academic anyway, unless someone is willing to write the code and submit a patch, or Miller is listening and caring.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Wed, 9 Aug 2006, Chris McCormick wrote:
For me that is not the case. For example, I might use my GOP datastructure envelope abstraction for several different things in one patch. I may use it to control the filter cutoff of something in one part of the patch, and somewhere else use it to control the volume of something. Now let's say I move the entire volume-controlling aparatus to a different part of the canvas, and then click the "load" bang in the [sssad/panel] state saving abstraction by Frank. Intuition says that the envelope should load the same data it has had all along, but with the method you proposed it would load some other data corresponding to this different location in the patch, maybe even the data of the cutoff-controlling envelope, which would be all wrong, or no data at all, which would just be irritating since your lovely hand crafted envelope would be gone forever.
Well, it might be confusing, don't know. Maybe its just that I think that I do not move things around that frequently, and if I do, I just have to save the settings together with the new patch. Anyhow, lets drop that idea then.
I don't mean to save the IDs into the abs.pd file. I mean to save them in the parent patch with the line which signals the creation of a new abs.pd(.) So something like this:
After the instantiation line: #X obj 24 583 abs my abs arguments; #I 54322345; ^^^ This is the unique ID generated by Pd.
Or even breaking backwards compatability: #X obj 24 583 54322345 abs my abs arguments; ^^^ This is the unique ID generated by Pd.
Ok, I see. I misunderstood. I must have been sitting on my brain.
The only way you can distinguish these 5 abstractions in a patch is by their position and the way they are connected to other objects. Or, by naming them, which is what we currently do.
I think there is a fourth way as I have indicated above; to associate some Pd generated ID with each abstraction instantiation in the parent patch. Nobody has to use this ID, but it's there if you want something more permanent than $0. It would make it easier for unnamed things to be saved by memento or sssad or state.
Then there is another can of worms; generating IDs unique across several patches put together at different times. Hmmm. Maybe the ID could be the unix timestamp + milliseconds at the time when the abstraction was first instantitated?
All of this is academic anyway, unless someone is willing to write the code and submit a patch, or Miller is listening and caring.
Ok, I get your idea. Although, you are right, its really in the guts of Pd and you have to add something that makes it possible to store your ID. I think a clean solution for that can only be implemented by Miller.
Günter
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Wed, 9 Aug 2006, geiger wrote:
Most of the time, if you have several abstractions of the same type in a patch, they do the same thing, so nothing is lost. If your patch only has one abstraction of each type, there is no problem anyhow.
I'll send you a virus that will rename all files to each other's name as long as they have the same file type. Nothing will be lost. :-]
Or rather, I can prove you that the amount of information that you will lose will be insignificant, that is, a sum of logs of factorials. If you have 750 jpegs and 300 pdfs and I scramble their filenames, you only lose log2(750!)+log2(300!) = 8128 bits = ONLY ONE KILOBYTE! imagine that compared to the humongous size of the pictures and documents!
what's missing in that reasoning: the bits lost are not as important as the patience lost.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 9 Aug 2006, Frank Barknecht wrote:
Yes, that's no problem. Btw: With "$1-tags" it also is possible to use the same tag for different instances of an abstraction so that they share the same settings which is very useful for dealing with polyphony.
Yes, actually the format should be like
MAIN/1/abs/3/subabs/4, then sending the data to
MAIN/1/abs/3/subabs would set all abstraction of that name in that patch.
Also, if you add the abstraction at the beginning, the whole data will be shifted one abstraction.
Urgh ... ;)
Urgh++ ;) ;)
Anyhow, not too different from adding and removing inlets and outlets.
inlets and outlets are the only thing in Pd where position really matters (ignoring internals like connections for now), and that's already a little problem, although we got used to it.
I do not think its a problem, but thats probably only me.
But you may remember proposals by Matju IIRC to introduce inlet arguments to specify which inlet should be at which position. I think, that was an idea carried over from jMax.
Yes, and I was against it because I am used to the ordering done in Pd. I think unless you make real user studies this is personal taste. (but then, who believes in user studies :)
Anyways I generally prefer the explicit approach Pd uses most of the time. Two patches that print the same should also behave the same and that isn't the case anymore if we rely on position alone to load data.
Not sure, because the patches behave the same, just the data is different, and you can also see this in the printout. The semantics is simple and not very different from the one that you use with the naming.
data abs/1 goes to the first abstraction called [abs]
data foo1 goes to the first abstraction [abs foo1]
actually it is even clearer in the first case, where you have the name of the abstraction where the data goes to included automatically. With your scheme you have to make sure that there is not another foo1 anywhere in the patch .. and beware there is one ...
Urghhhhh :)))
How did [state] handle this?
this didn't get handled by state, one had to use $1 to name states differently.
Günter
On Wed, 9 Aug 2006, geiger wrote:
Yes, and I was against it because I am used to the ordering done in Pd. I think unless you make real user studies this is personal taste. (but then, who believes in user studies :)
You see, the ordering done in Pd was also chosen because it was someone's personal taste. I don't see what's so inferior about my personal taste.
User studies... I'm a user, and I study myself, that's a user study.
About the "real" ones... it's easy to skew them; it doesn't have to be intentional; one just has to be skilled, confident AND naïve. I mean:
Pick users that never use pd, ask them to do tasks that never happen in real life, measure aspects that don't matter, but do so with everything in milliseconds and millimetres, proper sampling, compute standard deviation, compare to the bell curve, interpret hypotheses according to 95th centile, and WOW, you now have a perfectly realised study revolving around wrong assumptions.
(No statistics book will mention those wrong assumptions, because they are domain-specific.)
(ever measured a programmer's productivity by counting written lines of code? try measuring pd user productivity by counting how many objects there are in their patches. that's a technique used in industry.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 9 Aug 2006, Mathieu Bouchard wrote:
On Wed, 9 Aug 2006, geiger wrote:
Yes, and I was against it because I am used to the ordering done in Pd. I think unless you make real user studies this is personal taste. (but then, who believes in user studies :)
You see, the ordering done in Pd was also chosen because it was someone's personal taste. I don't see what's so inferior about my personal taste.
See, thats exactly what I wanted to say. Nothing is inferior about your personal taste. If you think I wanted to imply that then tell me how, and I try to make a clearer statement the next time.
User studies... I'm a user, and I study myself, that's a user study.
About the "real" ones... it's easy to skew them; it doesn't have to be intentional; one just has to be skilled, confident AND naïve. I mean:
Pick users that never use pd, ask them to do tasks that never happen in real life, measure aspects that don't matter, but do so with everything in milliseconds and millimetres, proper sampling, compute standard deviation, compare to the bell curve, interpret hypotheses according to 95th centile, and WOW, you now have a perfectly realised study revolving around wrong assumptions.
(No statistics book will mention those wrong assumptions, because they are domain-specific.)
(ever measured a programmer's productivity by counting written lines of code? try measuring pd user productivity by counting how many objects there are in their patches. that's a technique used in industry.)
:) Yeah, but sad thing is I have seen that in other "non-industrial" domains too. And it gets even worse, some people think that lines of code is directly proportionial to quality.
Günter
On Wed, Aug 09, 2006 at 11:35:43AM -0400, Mathieu Bouchard wrote:
On Wed, 9 Aug 2006, geiger wrote: I don't see what's so inferior about my personal taste.
Most definately not inferior. But if someone writes a piece of open source software it's their perjogative to design and code it however they want, users be damned. And if they design it in some way they like, and lots of people use it and like it too, well that's software evolution.
Evolution gave us intelligence. Democracy gave us George Bush. I know which one I like better. ;)
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Hi list,
Having fired the two largest email chains I've seen in pd-list (standalone instruments - multiple (same) ..), I felt sort of obligaded to see what is being said on them as it reached fields I don't understand yet. (btw, what is the infamous ==20)?
As a solution to my problem, considering the multible objects I took the first answer that I got (althought not tested yet) but, as the chain mail grew, my insecurity about the fist solution being the optimal grew alike (Frank I WILL test it, promise)!
Although I'm not confortable with programming, and not completely undestand what is said in the current chain mail, I have a proposition for the problem we are all facing.
Could we, when we summon (god, I like this word) an abstraction pass an abstraction-patch name which will affect the string/variable name of the setting included in the abstraction?
What I mean ....
We have an abstraction called myabs which includes a structure like this:
|-|
| | \
| |
|-|
\ \
\
[sssad volume $var]
|-|
| | \
| |
|-|
\ \
\
[sssad pitch $var]
Now, in the patch, we SUMMON two instances of myabs abstraction thus:
[myabs one] [myabs two]
So the sssad admin receives volume one, pitch one, volume two, pitch two.
What would you think?
if what I said is #$%#^#%, plz don't beat me up!
Regards,
Tasos
ΓñçóéìïðïéΓ₯ΓΓ΄Γ₯ Yahoo! ΓÑñΓ₯Γ¨ΓΓͺÑôΓ₯ ôÑ Γ₯Γï÷ëçôéΓͺà ìçΓΓ½ ìÑôÑ (spam); ΓΓ― Yahoo! Mail ÀéÑèΓΓ΄Γ₯Γ© ôçà ΓͺÑëýôΓ₯Γ±Γ§ ÀáΓÑôà ðñïóôÑóΓΓ‘ ΓͺÑôà ôùà Γ₯Γï÷ëçôéΓͺþà ìçΓáìΓôùà http://login.yahoo.com/config/mail?.intl=gr
Hallo, Tas Pas hat gesagt: // Tas Pas wrote:
Could we, when we summon (god, I like this word) an abstraction pass an abstraction-patch name which will affect the string/variable name of the setting included in the abstraction?
What I mean ....
We have an abstraction called myabs which includes a structure like this: [sssad volume $var]
Now, in the patch, we SUMMON two instances of myabs abstraction thus:
[myabs one] [myabs two]
So the sssad admin receives volume one, pitch one, volume two, pitch two.
What would you think?
if what I said is #$%#^#%, plz don't beat me up!
No, what you say makes perfect sense and actually that's kind of what I wrote in my first reply. However for reasons hidden inside [sssad] it is not possible to actually use two seperate arguments like [sssad volume $var], you can only use one single argument and the "$"-part has to be at the beginning of that, so what you should use is:
[sssad $var/volume] where "var" has to be an integer number like 1, 2, 3,...
So you can use [sssad $1/volume], or [sssad $2/vol] or [sssad $1volume] or [sssad $12_volume]. All these are functional and will do what you want to achieve. However these next three versions will *not* work: [sssad volume/$1] and [sssad $1 volume] and [sssad volume $1]
Personally I like the "$x/name"-style the most.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 9 Aug 2006, Frank Barknecht wrote:
But you may remember proposals by Matju IIRC to introduce inlet arguments to specify which inlet should be at which position. I think, that was an idea carried over from jMax.
Yes, that's straight from jMax. That means [inlet],[outlet] would work more like [r],[s] but with nonnegative integer arguments: if inlet/outlet numbers are duplicated then it's like when [r]/[s] symbols are duplicated (but always local to the subpatch/abstr of course!). The number of inlets/outlets is the biggest index plus 1, supposing the indices start at 0 as it is in both Pd's file format and jMax's [inlet]/[outlet] objects (and jMax file format of course). An alternative that I thought about is to skip unused numbers, to prevent creation of 1000000 inlets by just making one [inlet 1000000]. Then the number of inlets would be the total number of [inlet] objects minus duplicate indices.
Anyways I generally prefer the explicit approach Pd uses most of the time.
It's generally better for dynamic patch creation. It's very much possible getting used to the fact that positions are useless for all objectboxes except [inlet] and [outlet], but then it may add complications in our patches in order to deal with it. I always think about that sort of thing because my dream is always of making patches that contain nothing and that do everything, and short of being able to do that (heh), the minimum necessary is the maximum i aim for (usually), but of course, that's all relative to the feature set I want.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 9 Aug 2006, Mathieu Bouchard wrote:
Anyways I generally prefer the explicit approach Pd uses most of the time.
It's generally better for dynamic patch creation.
Actually, more important than dynamic patch creation is the ability to just move things around and put them in their natural place without destroying the carefully-chosen order. Most of all, think of patches made in a vertical style, because it's what naturally fits:
[inlet] | [*][inlet] | [+][inlet] | [%][inlet] : : [outlet]
Then in order to make this thing work predictably, I can't put things in a clean vertical order, i have to place the objects along a diagonal, or switch to a horizontal style:
[inlet] [inlet] [inlet]
| ,-. | ,-. | .- - - .
[* ] / [+ ] / [% ] / [outlet]
---'---' `---'
Which is often not natural in Pd, and I'd almost say, not often natural. (it really depends on what's in the patch exactly, but I'd rather choose how I place my objects without interference)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hey all,
I missed this reference.
Anyhow as for pixelTANGO when you mess with the patch structure you break the names. So the user has to:
a. close the patch and reopen it after the change b. send a magic message to update the "tags" (This is not yet implimented)
so I have not found any brilliant solution to the issue.
Note in pixelTANGO I'm only concerned with abstractions in each chain, so that "tags" are generated based on the abstractions position in the chain, assuming everything is flat... (no nesting) I have also not resolved issues with chains that split... (one video on multiple objects).
.b.
Frank Barknecht wrote:
Hallo, geiger hat gesagt: // geiger wrote:
One could generate the ID automatically based on the name of the abstraction, its position (relative to the other abstraction with the same name) and the ID of the parent patch.
This way it might be possible to come up with unique ID's without having to name your abstractions individually.
e.g
MAIN1/abs4/subabs3
would be the 3rd abstraction "subabs" (ordered with increasing x then y) in the 4th abstraction "abs" in the main patch "MAIN".
I thought of that as well, but how do you deal with edits of a patch? Say you delete or recreate an abstraction instance, how should Pd know which abstraction is used for which saved data? Maybe Ben Bogart can say something about how he did it in picelTANGO, where auto-generated "tags" are in use as far as I understand.
Ciao
-
B. Bogart -
Chris McCormick -
Frank Barknecht -
geiger -
Mathieu Bouchard -
Tas Pas