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 <[email protected]> wrote: > 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 > [email protected] > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users _______________________________________________ chuck-users mailing list [email protected] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
