What if adding an element to an existing trigger object shifted all the outputs to the right of where the new one was inserted, instead of adding outputs to the right? Maybe a similar thing for deleting elements, instead of deleting outputs past a certain number, it could delete them from the middle? I can't think of any reason the current way would be better, but I may be missing something.
-Chuckk
Chuckk Hubbard wrote:
I can't think of any reason the current way would be better, but I may be missing something.
i guess the reason is: simplicity on the implementation side. pd has no idea about which part of the object has been deleted, it just destroys the old object (e.g. [t b b b]) and instantiates a new object (e.g. [t b b]); btw. sometimes it is pretty hard (even for humans and cats) to know which part has been deleted by just looking at the "before and after"
i guess we all agree that it would be a fine feature. i guess nobody wants to implement it, though...
mfg.asdr. IOhannes
On 6/26/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Chuckk Hubbard wrote:
I can't think of any reason the current way would be better, but I may be missing something.
i guess the reason is: simplicity on the implementation side. pd has no idea about which part of the object has been deleted, it just destroys the old object (e.g. [t b b b]) and instantiates a new object (e.g. [t b b]); btw. sometimes it is pretty hard (even for humans and cats) to know which part has been deleted by just looking at the "before and after"
i guess we all agree that it would be a fine feature. i guess nobody wants to implement it, though...
mfg.asdr. IOhannes
Didn't think of that. I recall that now, the old object is deleted. Oh well.
On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
i guess the reason is: simplicity on the implementation side. pd has no idea about which part of the object has been deleted, it just destroys the old object (e.g. [t b b b]) and instantiates a new object (e.g. [t b b]); btw. sometimes it is pretty hard (even for humans and cats) to know which part has been deleted by just looking at the "before and after"
even for dolphins and mice and betelgeuseans and paranoid androids.
i guess we all agree that it would be a fine feature. i guess nobody wants to implement it, though...
[t] needs to be a GUI object with right-click "Insert Outlet..." and "Delete Outlet..." or something.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
[t] needs to be a GUI object with right-click "Insert Outlet..." and "Delete Outlet..." or something.
Uuhaa, that sounds terrible. I'd rather create a [t a b a b a b a b] big enough in advance... ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
[t] needs to be a GUI object with right-click "Insert Outlet..." and "Delete Outlet..." or something.
Uuhaa, that sounds terrible. I'd rather create a [t a b a b a b a b] big enough in advance... ;)
hehe, right :)
often I keep "emergency triggers", i.e.:
...
|
[t a b b f]
. | \
.. ...........
so if I have to insert something after, I use the "a" outlet: ... | [t a b b f f] | ........\\ [t a b f] .... ... | \
[just my two (euro)cents] :)
Federico
Hallo, Federico hat gesagt: // Federico wrote:
often I keep "emergency triggers", i.e.:
... | [t a b b f] . | \
.. ...........so if I have to insert something after, I use the "a" outlet: ... | [t a b b f f] | ........\\ [t a b f] .... ... | \
That's a good idea.
Personally I stopped using anything but "a" or "b" inside a trigger, because Matju convinced me, that trigger is not well suited as a type converter, so I'm only using it to specify execution order and as a [bang] shortcut, because that's needed very often.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Frank Barknecht wrote:
Hallo, Federico hat gesagt: // Federico wrote:
often I keep "emergency triggers", i.e.:
... | [t a b b f] . | \
.. ...........so if I have to insert something after, I use the "a" outlet: ... | [t a b b f f] | ........\\ [t a b f] .... ... | \
That's a good idea.
Personally I stopped using anything but "a" or "b" inside a trigger, because Matju convinced me, that trigger is not well suited as a type converter
why? actually I have devel_0_39 and this code:
[20 30 40( | [t l f b] | | | | | [print b] | [print f] [print l]
produces this output: b: bang f: 20 l: 20 30 40
so it can be good for trigger list/floats separately... you have only to know, if you work with symbols (s) then you can only use 's' or 'a' inside triggers. (please correct me if I am wrong)
Federico
Federico wrote:
Frank Barknecht wrote:
Personally I stopped using anything but "a" or "b" inside a trigger, because Matju convinced me, that trigger is not well suited as a type converter
why?
actually I have devel_0_39 and this code:
[...]
your code is just prefectly valid on vanilla pd too. however:
matju convinced frank, that it is a bad idea to have one object do 2 things which are totally unrelated. defining execution order and casting types IS unrelated, therefore it is bad practice (according to matju. and i agree) to use the trigger object for anything else but defining execution order.
mfg.asd.r IOhannes
On Sat, 1 Jul 2006, IOhannes m zmoelnig wrote:
matju convinced frank, that it is a bad idea to have one object do 2 things which are totally unrelated. defining execution order and casting types IS unrelated, therefore it is bad practice (according to matju. and i agree) to use the trigger object for anything else but defining execution order.
Actually, it's not so much that [t] does both ordering and casting, it's that it doesn't even do any casting worth mentioning. Replacing any float by the "symbol" symbol isn't casting, it's a big nothing, it's pure uselessness.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I've never really seen it as anything but an event flag. A stack of [t b b b b ] so that, as I now understand, I can sequence the evaluation order of my code better. And yes for that exact purpose it rather sucks, because if you want to insert an earlier one you have to move everything. Perhaps the obvious thing that nobody is saying is to change the persistance characteristics of the trigger instance. Have it make a copy of itself which gets used to construct the new one? Wouldn't that be generally useful to be able to insert new parameters in any order for other objects? What are the dangers?
But as for type management, yeah, its definitely a Badthing(tm) right. Better to use inlets and not to build complex datastructures with lists and pointers to be passed about so early in the design. At the moment you sort of have to manage the control parameter layer of a synthesiser yourself, using routes and selects, packs and unpacks to mange control vectors of your own definition. In between goes a layer of type-checking, range limiting with [max]/[min], and stuff like that to make sure all your parameters are where they should be. I'm learning to use datastructures a bit now. Anyway it seems in Pd, perhaps because passing parmeters to subpatches and abstractions isn't formal, and there's not a handy way to wrap the parameters of a block of code, that trigger gets abused.
It's hard to say where exactly the type handling of Pd could be improved without taking the lid off a huge can-o-worms, but I can feel its limitations.
Andy
On Sat, 1 Jul 2006 21:14:10 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Sat, 1 Jul 2006, IOhannes m zmoelnig wrote:
matju convinced frank, that it is a bad idea to have one object do 2 things which are totally unrelated. defining execution order and casting types IS unrelated, therefore it is bad practice (according to matju. and i agree) to use the trigger object for anything else but defining execution order.
Actually, it's not so much that [t] does both ordering and casting, it's that it doesn't even do any casting worth mentioning. Replacing any float by the "symbol" symbol isn't casting, it's a big nothing, it's pure uselessness.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 4 Jul 2006, padawan12 wrote:
Perhaps the obvious thing that nobody is saying is to change the persistance characteristics of the trigger instance. Have it make a copy of itself which gets used to construct the new one?
jMax had that feature: in addition to having a constructor and a destructor, a class could optionally define a "reconstructor" which would be called instead of deleting+recreating.
Wouldn't that be generally useful to be able to insert new parameters in any order for other objects? What are the dangers?
Even with a "reconstructor", the reconstructor can't know where text has been inserted except by comparing strings.
Doing what you want with [t] is best done using a specialized GUI for that object class. This is done by setting up a t_widgetbehavior, writing several pages of C code and recompiling. (to do this in DesireData, you don't need to recompile and you don't need to write C code)
Anyway it seems in Pd, perhaps because passing parmeters to subpatches and abstractions isn't formal,
What do you mean "not formal" ?
BTW subpatches don't take any creation arguments (just a name). Abstraction instances do.
and there's not a handy way to wrap the parameters of a block of code, that trigger gets abused.
I don't know what you mean here. Want to give an example?
It's hard to say where exactly the type handling of Pd could be improved without taking the lid off a huge can-o-worms, but I can feel its limitations.
I don't think that we are talking about types?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I don't think that we are talking about types?
maybe that the type system necessitates "using routes and selects, packs and unpacks to mange...In between goes a layer of type-checking"
im pretty sure the way all the other systems have avoided this confusing-to-n00bs 'list thats not a list due to prepended non-list selector' thing is by having the selector painted right on the object:
http://gstreamer.freedesktop.org/data/images/gst-editor/gst-editor-ambisonic... http://www.nongnu.org/om-synth/gated_sine.png http://img.photobucket.com/albums/v287/joeedh/MusicAppScreenie3.png
even as a non-newbie its useful to see all the methods without traipsing into a gigantic class-selector scrolly-list, or god forbid, the documentation.
this should be doable in DesireData as some kind of inheritable superclass, utilizing data from the class-inspector API, right?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, padawan12 hat gesagt: // padawan12 wrote:
I've never really seen it as anything but an event flag. A stack of [t b b b b ] so that, as I now understand, I can sequence the evaluation order of my code better. And yes for that exact purpose it rather sucks, because if you want to insert an earlier one you have to move everything. Perhaps the obvious thing that nobody is saying is to change the persistance characteristics of the trigger instance. Have it make a copy of itself which gets used to construct the new one? Wouldn't that be generally useful to be able to insert new parameters in any order for other objects? What are the dangers?
The problem with in/outlet management happens with all objects that generate their outlets on demand. Besides trigger this also involves route, select, (un)pack etc.
In a perfect world one would always create these objects with exactly the needed arguments in advance, but then it is one of the strong aspects of Pd that it leads to a more experimenting, playful style of development where changing object arguments can happen quite often.
There also is a related issue: Currently it is not possible to change the in/outlet count through messages, AFAIK, which hits everyone developing with [pyext] a bit all the time. ;)
But well, personally I must say I don't get hit by this problem as often as some years ago anymore, so it seems there must be some automatic workarounds in effect in my Thinking In Pd already...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 3 Jul 2006, Frank Barknecht wrote:
There also is a related issue: Currently it is not possible to change the in/outlet count through messages, AFAIK, which hits everyone developing with [pyext] a bit all the time. ;)
GridFlow will soon provide API functions for removing inlets/outlets (it already allows adding inlets/outlets). This is because we have a project in which Rightclick Properties is supposed to allow to select between several variants of a class, which sometimes have differing numbers of inlets/outlets.
I will also look into a way to refresh the display after a change of inlets/outlets.
But well, personally I must say I don't get hit by this problem as often as some years ago anymore, so it seems there must be some automatic workarounds in effect in my Thinking In Pd already...
"Thinking in Pd"? is that the title of your new book? =)
http://www.mindview.net/Books/TIPython
http://www.mindview.net/Books/TIJ/
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
There also is a related issue: Currently it is not possible to change the in/outlet count through messages, AFAIK, which hits everyone developing with [pyext] a bit all the time. ;)
a late comment on this (just returned from abroad residency): Setting inlet/outlet count inside the script will most probably become deprecated (because of the mentioned facts). Instead use something like [pyext 2 3 module.class args]
greetings, Thomas
On Sat, 1 Jul 2006, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
[t] needs to be a GUI object with right-click "Insert Outlet..." and "Delete Outlet..." or something.
Uuhaa, that sounds terrible. I'd rather create a [t a b a b a b a b] big enough in advance... ;)
But I mean, what happens when "in advance" is so not in advance that it's in fact happening in the future?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Maybe there could be a message just for trigger objects that shifts/cycles all the outputs left or right? But then how often would that get used... probably never. Maybe as a right-click option? I've done the trick with inserting another trigger on the leftmost output too, but it can get sloppy and hard to decipher when you end up with a couple in series.
I don't see why one would use 'a'. Does anyone ever send floats, lists, and symbols to the same trigger? I mean, the receiving object is just as likely to have a problem with it as the trigger object itself.
On 6/26/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Chuckk Hubbard wrote:
I can't think of any reason the current way would be better, but I may be missing something.
i guess the reason is: simplicity on the implementation side. pd has no idea about which part of the object has been deleted, it just destroys the old object (e.g. [t b b b]) and instantiates a new object (e.g. [t b b]); btw. sometimes it is pretty hard (even for humans and cats) to know which part has been deleted by just looking at the "before and after"
i guess we all agree that it would be a fine feature. i guess nobody wants to implement it, though...
mfg.asdr. IOhannes
Quoting Chuckk Hubbard badmuthahubbard@gmail.com:
I don't see why one would use 'a'. Does anyone ever send floats, lists, and symbols to the same trigger? I mean, the receiving object is just as likely to have a problem with it as the trigger object itself.
i do. there are objects that accept symbols, floats, lists and all kind of other stuff. there are even objecs that output different messages.
mfg.ssd. IOhannes
Chuckk Hubbard schrieb:
I don't see why one would use 'a'. Does anyone ever send floats, lists, and symbols to the same trigger? I mean, the receiving object is just as likely to have a problem with it as the trigger object itself.
Maybe I'm not really clear about the problem, but I often use for example [t b a b] to trigger things with the bangs before and after passing e.g. an OSC message.
Best Urs
On Sat, 1 Jul 2006, Chuckk Hubbard wrote:
I don't see why one would use 'a'. Does anyone ever send floats, lists, and symbols to the same trigger? I mean, the receiving object is just as likely to have a problem with it as the trigger object itself.
Suppose you make your own demux abstraction that automatically cycles through outputs. You want to support floats, symbols, pointers, lists, and others. How do you not use [t b a] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
I don't see why one would use 'a'. Does anyone ever send floats, lists, and symbols to the same trigger?
I guess, everyone does: A list-message (starting with "list ...") with only one element *is* a float or a symbol, depending on the first element. ;)
I don't use anything but "a" or "b" in a [trigger] because I like these things to be explicit for readability etc. I rather use a [f], [list] or [symbol] after the [trigger], because then I can better spot any errors.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi,
Doing what you want with [t] is best done using a specialized GUI for that
object class.
Maybe an easier way: Seeing as we can select cables (ok not multiple ones yet...), and that hitting left and right arrows already works for moving objects around, I was thinking a nice way to deal with the trigger issue would be to select multiple cables, say all the cables coming out of the trigger, and then hit left/right with the cursor near the trigger object in order to shift the outlet they are attached to by one to left/right respectively.
So if you had:
[t b a b a] | | | |
to several objects and you wanted to insert an 'a' at the beginning of the trigger object, so it was executed last, you could make the trigger object first:
[t a b a b a] | | | |
Then select all the cables and hit right once:
[t a b a b a] | | | |
whoops I just realised this will look crap on most normal fonts. oh well. So if you wanted to insert an 'a' in the middle, you could just select the cables to the right of the insertion and hit right once! easy?? any thoughts?
I guess if the mouse cursor is nearer the destination objects when the left/right is pressed it will shift the inlet numbers of these objects that the cables are connected to.
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=-
I have no idea how easy implementation would be, but I think this would be a great feature. I guess pack would be the only object where the inlets might need to change? Maybe [expr].
On 7/4/06, matthew jones mj@isvr.soton.ac.uk wrote:
Hi,
Doing what you want with [t] is best done using a specialized GUI for that
object class.
Maybe an easier way: Seeing as we can select cables (ok not multiple ones yet...), and that hitting left and right arrows already works for moving objects around, I was thinking a nice way to deal with the trigger issue would be to select multiple cables, say all the cables coming out of the trigger, and then hit left/right with the cursor near the trigger object in order to shift the outlet they are attached to by one to left/right respectively.
So if you had:
[t b a b a] | | | |
to several objects and you wanted to insert an 'a' at the beginning of the trigger object, so it was executed last, you could make the trigger object first:
[t a b a b a] | | | |
Then select all the cables and hit right once:
[t a b a b a] | | | |
whoops I just realised this will look crap on most normal fonts. oh well. So if you wanted to insert an 'a' in the middle, you could just select the cables to the right of the insertion and hit right once! easy?? any thoughts?
I guess if the mouse cursor is nearer the destination objects when the left/right is pressed it will shift the inlet numbers of these objects that the cables are connected to.
Matt
-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org -=-=-=-=-=-=-=-=-=-=-=-
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
carmen -
Chuckk Hubbard -
Federico -
Frank Barknecht -
IOhannes m zmoelnig -
Mathieu Bouchard -
matthew jones -
padawan12 -
Thomas Grill -
Urs Liska -
zmoelnig＠iem.at