----- Original Message ----- > From: Frank Barknecht <[email protected]> > To: Jonathan Wilkes <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Monday, November 5, 2012 9:48 AM > Subject: Re: [PD] Licensing issues (was rjdj is gone, robotcowboy is coming > ...) > > Hi, > > On Sun, Nov 04, 2012 at 05:48:23PM -0800, Jonathan Wilkes wrote: >> [list of the table names( >> | >> | [r midi_note_number] >> | / >> | [set $1( >> | / >> [ ( >> | >> >> If the essence of "seeing the light" regarding Pd Vanilla is that > it's more >> efficient to use what's already there to read/write/share patches, I > don't >> see why you'd prefer the abstraction to such a straightforward idiom to >> solve your task. > > For m_symbolarray the main reason was speed and as a side-effect allowing > "holes" in the array. Accessing an array (even one in a data > structure) is a > lot faster than sending around a long list every time a lookup is needed. > m_symbolarray made a patch run nicely on an iPhone that was totally > overloading the device before.
Oops, my ascii art above should have [set, adddollar $1( in it. How many table names total were there in the patch that was overloading the device? -Jonathan > > Of course often you just can get away with the usual approach that you > outlined > above, and please do so, if you don't run into problems. > > But if a) the number of names (i.e. the list length) gets large or b) you have > to activate this idiom many, many times, you can hit a wall. And it's quite > easy to make a) and b) with sample players if you play polyphonic music with > many instruments in it. Here m_symbolarray is one way out. > > Ciao > -- > Frank Barknecht _ ______footils.org__ > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
