[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Coding vs patching: would you eat soup with a fork?
On 3 May 2009, at 02:19, Jonathan Wilkes wrote:
Hi Scott,
I'm a pd user who's learning sc at the moment, and I've been
playing around with porting your example above to pd. Though not as
elegant/efficient as the sc code, none of the solutions I came up
with requires the user/programmer to make all the relevant objects
themselves. A patch that works for p=20 works equally well for
p=100, and is merely a matter of changing a creation argument to an
abstraction (or the input to an inlet). The "do" method is
simulated by use of dynamic patching.
I don't use Max but I would be very surprised if something
similar can't be done.
Well that's a fair point, and normally when I've shown this example to
people I end with discussing poly(~) or javascript in Max. I can't
really comment on PD as I don't know it very well. (To be honest I got
as far in the manual as the point where it says multiple objects
connected to the same outlet execute in the order they were connected,
and pretty much gave up. ;-)
It's certainly possible to do iterative things with poly and poly~,
although I would point out that these are really intended as voicers
rather than general purpose iterator/constructors, which I find makes
them a bit clumsy to use sometimes. As well, certain obvious things
like connecting iterations in a chain (or more complex
interconnections) are not straightforward.
Javascript is fine, and is vastly superior to the patcher scripting it
has superseded (wherein a significant part of the doc was open your
patch as a text file and try to figure out what's happening). But then
you're programming in JS, not Max, and I think SC is nicer than JS
anyway.
IAC, I stand by my main point, which was that what seem to be the
strengths of Max in simple patches – the code is effectively a data
flow visualisation, and its use of a physical-world metaphor of
persistent physical objects and cables – quickly become a liability in
complicated patches. In those cases I find something like SC much
easier to read and follow. Text languages (gross generalisation) are
just better at some things than visual patching languages, although
the reverse is also true of course.
S.
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/