On Jun 23, 2008, at 1:01 PM, Andy Farnell wrote: > On Mon, 23 Jun 2008 11:38:27 +0200 > Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > >> >> Perhaps these could have more descriptive names, especially if there >> was a "tabread", etc. library. Some quick ideas: >> >> [tabread_tweak~] >> [tabread_transpose~] > > Hard to argue against, but I'm such a fan of Vanilla style compactness > and brevity. :)
This compactness only really helps speed up the typing of code. It hinders the reading of code and the learning of code. Plus it means that us mere mortals, who cannot remember what "c" in [tabread4c~] means, it means we have to constantly ride the reference pages rather than just writing code. Trading all this for typing a few less keystrokes seems to me a very bad deal. Apparently, people who use Smalltalk, Java, Python, Ruby, Obj-C and even sometimes C++ seem to agree. .hc > > This may have been discussed before, but to widen the discussion... > > I got thinking about a great discussion I read on music-dsp or > harmony-central > (sorry can't find the ref now) about sampler design. Since , as > matju points out > there's no interpolation advantage at unity pitch I remembered the > hoopla > proposed to make 'one size fits all' compromise designs. The > conclusions > were something indicationg that a general purpose [sampler~] (?) > object would > use the approach taken by Emu or Native Instruments, selecting the > best > method depending on the case. > > There are maybe 5 classes, each requiring different approaches for > quality > results. > > No transposition - very common for drum machines etc > > Very small transpositions - microtonal variations on existing > scale multisamples > > Transpositions down within a fifth > > Transpositions down greater than a fifth > > Transpositions up > > With the interpolation choices being none, linear, cubic, > oversampled sinc > and several variations of decimation/resampling schemes. > > I'm not sure where 'very small' transpositions fit into that, aren't > they actually a difficult case? > > When people talk about the 'sound quality' of Pd I suspect they are > more > casual musical users who largely do sample based work. It would be > great to have a whole suite of [tabreadX~] for the programmers. But > for > more casual users I think extended might greatly benefit from a > 'just works' > [sampler~] object. You could give it arguments along the lines of > polyphony, > outputs etc... It could even do multi-sample (with many tables). > Add that > to a file reader [soundfiler-kontakt] or [soundfiler-akai] to > automatically > generate the tables for [sampler~] and Pd would become quite > attractive > to a larger user base I think. > > > a. > > > > > >> >> .hc >> >> >> >>> >>> -- >>> Use the source >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >>> listinfo/pd-list >> >> >> >> >> --------------------------------------------------------------------- >> --- >> ---- >> >> kill your television >> >> > > > -- > Use the source ------------------------------------------------------------------------ ---- "It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
