CUNHA Claudio wrote:
But I must to convert a PD patch in Max/MSP and the problem is that I am not the person who creates the PD patch... If I don't know the original order of the PD patch how can I use the triggers
well, if the original Pd patch does not use triggers to explicitely define the execution order, then it is plainly buggy.
so you are basically requesting a converter that fixes bugs for you. while this would certainly be a cool thing to have (the software society is waiting for ages for such a feature...), there is none.
you might still get away with that (e.g. if you don't trigger any race conditions)
ifthe converted patch is borken you have serveral options: - kick the upstream author to write patches with fewer bugs - fix the pd-patch by hand and submit the changes to the upstream author - fix the pd-patch by hand everytime the upstream author releases a new version - fix the max-patch by hand everytime the upstream author releases a new version
i would go for one of the first two options, as they imply less work on the long run. if you are doing a one-time conversion, it doesn't really matter (but you might still want to kick the upstream author)
mfga.sdr IOhannes
On Wed, 26 Sep 2007, IOhannes m zmoelnig wrote:
well, if the original Pd patch does not use triggers to explicitely define the execution order, then it is plainly buggy. so you are basically requesting a converter that fixes bugs for you.
This is why DesireData has an entry in the Help menu that says "Do What I Mean". Of course it'll never go much further than asking the user "This would be a cool feature, eh?".
I mean that the problem of fixing bugs automatically like that is one of mind-reading. The process of writing automatic test patches is one of making an executable specification. This is almost the closest that one can get to automatic debugging.
I can imagine a tool that would use automatic tests in order to fix simple common bugs, but the complexity of that tool would very much exceed any benefits. It's much better to spend that effort on making shortcuts in the editor in order to quicken the process of patching a solution to a bug. It's also better to educate oneself to prevent bugs instead of fixing them when one would rather be already working on something else instead.
while this would certainly be a cool thing to have (the software society is waiting for ages for such a feature...), there is none.
The most important problem in software is to explain in enough detail what a piece of software should do. The rest pales in importance, although this latter part may look bigger than it really is, when people try to skip the former part. (when i say former and latter I don't mean that all the design of everything has to be done in advance, far from it)
ifthe converted patch is borken you have serveral options:
- kick the upstream author to write patches with fewer bugs
- fix the pd-patch by hand and submit the changes to the upstream author
- fix the pd-patch by hand everytime the upstream author releases a new
version i would go for one of the first two options, as they imply less work on the long run.
tee-hee. it's quite often that the 3rd option is actually less work, even in the long run; but usually it's something that can only be known in retrospect, not beforehand. (I'm not talking about one-time conversions)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
IOhannes m zmoelnig -
Mathieu Bouchard