I've honestly never really kept track of memory use. I've had some
Processing stuff run slowly, but only because I've added visualization
that would be impossible/super hard in Pd/Max. That's usually when I
migrate again to OpenFrameworks...
Also:
My last message was somewhat misleading: you don't have to think about
an event loop in Processing either.
Still, I personally find there's less mental overhead involved in
using Pd/Max for UI-type stuff. I expect you'll find the same, since
you're already accustomed to using Pd.
Having said that, definitely check out Processing (or a similar tool
like OpenFrameworks, which I'm really into) if you're at all
interested in generating graphics or video (maybe even based on events
sent by your audio tool). I find that kind of thing really fun to work
with.
On Thu, Sep 11, 2014 at 2:31 PM, Peter Lutek
On 2014-09-11 15:08, Andrew Monks wrote:
I'll always use Pd/Max when I'm livecoding, so that I can easily add UI elements on-the-fly as I need them. When livecoding I don't really care about how pretty my interface is since it's for one-time use.
BINGO! thanks, andrew!
that's what i was starting to think, reading about how Processing works... and Pd has the benefit that i already know it! :)
although, i suppose, one could end up using more system resources with Pd, versus a compiled solution like Processing... do you have any direct comparisons of size/load for things you've built in both? not likely to be much of an issue for something just providing a front-end GUI, though, eh?!
cheers! .pltk.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users