hi thomas,
thanks for your work, and bringing future vasp direction to the forum, and yes, i care!
1> usage:
vasp is a critical addition to most of my pd compositions these days, i use it essentially for sample based analysis (zero-crossings, peaks, density, etc) and minor editing and transformations of arrays (normalize, crop, pitch shift, enveloping, etc).
i generally have subpatches of analytical vasp objects for each array, which operate on soundfiler action or transformation change, and output the results as lists, which i use for algorythmic sequencing, and interpolation information (ie. morphs)
the transformation objects are maninly used for multipurpose sample editing, however i do generally normalize samples on array change. i find being able to tweak and edit samples non-rt within pd is an absolute luxury, and although pd has issues with lengthy arrays, and is missing some graphical objects that would make editing simpler (i'm working on it), i think this an important extention to pd's rt focus.
2> real-time response
i prefer vasp as a background processor, so i'm not concerned by real-time responsiveness, however this may change if i begin to use vasp differently.
3> object structure
i like the current multi-object aproach of vasp and have found it intuitive on learning (the documentation is great, thanks) as it gently mirrors pd's rt object model. i'm not sure how you plan to implement the python model, so i don't think i'd be prepared to make a comment on which is better. certainly the multi-object model works more seamlessly into the pd programming logic, although it may not be the most efficient way of expressing non-rt events. i think perhaps if i could express vasp routines in a single scriptlet, i would use it that way, but i still believe that for vasp to be intuitive to new users in pd it needs singular objects.
so, could you please outline your ideas for the python based vasp so that i can better understand how the app would function.
hmm.. i think that sorta sums me up!
ciao..
dmotd