Is there any way to change the order in which the objects are evaluated
other than
deleting the too early one and inserting it again?
For the kind of work that I am doing that would couse havoc in most of
the cases.
Apart from that I find it very inconvinient, that the program does not
give any imformation
on that important matter. (hope I did not overlook some important
feature here)
Is there any remedy in the pipeline? if not, then here is my feature wish:
objects according to their indices (with some internal decision method if two ore more objects come with the same index)
next object in order of evaluation. Shift Tab would jump to the previous object. this would make debugging really easy.
avoid any unwanted unit delays) but this would have to be calculated whenever the signal routing is changed. (=whenever a wire is introduced or deleted) I'd rather prefer to do it manually also because that would sometimes give me a unit delay for free + it saves pd from another additional overhead.
best regards
Andreas Sumerauer .
Is there any way to change the order in which the objects are evaluated other than deleting the too early one and inserting it again? For the kind of work that I am doing that would couse havoc in most of the cases. Apart from that I find it very inconvinient, that the program does not give any imformation on that important matter. (hope I did not overlook some important feature here)
It may not be the best solution either, but MaxMSP does it in a right to left order regarding the x coordinates of the objects. That way one immediately knows the order of execution. The drawback is, that with complicated patches editing (moving around objects) often destroys this order irreversibly. I think hiding the ordering number inside a property dialog is still to incommodious. One solution could be to have a special editing mode where the order is indicated by numbers (or colors?) upon the objects for each branching of cords.
T
Thomas Grill schrieb:
It may not be the best solution either, but MaxMSP does it in a right to left order regarding the x coordinates of the objects. ...
Oh please not. I never worked with Max MSP but that does not make too much sense to me either.
I think hiding the ordering number inside a property dialog is still to incommodious.
Ok,... I hope You like the tab Idea at least?
One solution could be to have a special editing mode where the order is indicated by numbers (or colors?) upon the objects for each branching of cords.
Would be fine with me. But why another editing mode? I wouldn't mind seeing the numbers (colored labels could be a very useful addition too) in the current edit mode.
regards
Andreas
hi all,
I dont want to be facetious (however ones spells it), but I have found that it often doen't matter what execution order you have. And when it does, there is a solution. The trigger object, abbreviated "t", allows you to send exactly the signals in the right order to where you want them. No wierd background property boxes, all the functional properties on the surface where they belong. Isn't that part of the PD philosophy?
chrz,
tm
Andreas Sumerauer wrote:
Thomas Grill schrieb:
It may not be the best solution either, but MaxMSP does it in a right to left order regarding the x coordinates of the objects. ...
Oh please not. I never worked with Max MSP but that does not make too much sense to me either.
I think hiding the ordering number inside a property dialog is still to incommodious.
Ok,... I hope You like the tab Idea at least?
One solution could be to have a special editing mode where the order is indicated by numbers (or colors?) upon the objects for each branching of cords.
Would be fine with me. But why another editing mode? I wouldn't mind seeing the numbers (colored labels could be a very useful addition too) in the current edit mode.
regards
Andreas
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Thu, 5 Sep 2002, Andreas Sumerauer wrote:
- the sorting could of course be done automatically (with the aim to
avoid any unwanted unit delays) but this would have to be calculated whenever the signal routing is changed. (=whenever a wire is introduced or deleted) I'd rather prefer to do it manually also because that would sometimes give me a unit delay for free + it saves pd from another additional overhead.
implement order of evaluation using the "fork" object like in jMax. I mentioned that in a previous feature request list.
the "fork" object has 1 inlet and N outlets. It forwards everything it receives to all of its outlets, from right to left.
matju
hi Mathieu,
I do know about a simple control object [fork], but I think Andreas meant sorting of the dsp chain, not control message passing? Do you mean anything else, than the simple fork?
Btw, the usual idiom is to use [t a a... ] -- probably more verbose than fork, but making the object stretched to accommodate for the outlets. No way to parameterize the number of outlets, of course, but why one should want to do that without being able to parameterize the number of connections?
Krzysztof
Mathieu Bouchard wrote: ...
implement order of evaluation using the "fork" object like in jMax. I mentioned that in a previous feature request list.
the "fork" object has 1 inlet and N outlets. It forwards everything it receives to all of its outlets, from right to left.