Re:sampler

[ccastiglione]

[Ben sez]
>I've been thinking about the sampler machine / wavetable. ...

>There could be a global wavetable, with each entry having the
>visible parameters 
>
>[<index> <name> <filename> <middle-c rate>]
>
>and whatever else would be necessary internally.  Keeping the samples in
>external files would make saving songs more efficient and editing easier.

But -- harder to manage and distribute.  So, I say (having lately learned the
same lesson about sustanato), given a choice, do both!  Allow users to save
samples either inline or by external reference.  As for which should be the
default, well then that's another debate.  My preference is for inline as
default, external as option, if only because that's what tracker users have come
to expect.

>Each instrument could be a machine.  It could use only one sample across
>the entire range of notes, but would allow the possibility of
>arbitrarily assigning samples to notes / note ranges.

Yes!  I love the option of sample / instrument mode in Impulse!  The envelope
functions in Buzz provide some of the instrument functionality from IT but I
still don't think Buzz comes close in either flexibility or useability.  The
fact that you would default to sample mode (where envelopes and note mapping are
not issues) and then work your way up to instrument mode when you were ready for
the added complexity was brilliant.

I don't think the idea of "instrument as machine" makes sense to me though.  The
wavetable is a global resource to be used by machines, so it shouldn't enforce
specific behavior, just provide services for machines.

Uh -- that made sense, right?

>It would have volume and pan envelopes (and maybe a filter envelope), NNAs 
>(new note actions - to choose between note off and sustain when a new note 
>occurs)

Buzz has an interesting (if initially confusing) method of handling envelopes. 
Apparently, it's the machine devs' job to notify Buzz of which parameters are
envelope-controllable.  When you use the envelope editor on the wavetable page,
it allows you to specify a separate envelope PER waveform PER machine PER
env-controllable attribute!  Only attributes for loaded machines which support
envelopes show up in the list.

I agree that NNA's are a powerful concept, but I have the feeling that it's one
of those things that's best left to the machine devs.  I mean, it's a specific
behavior performed on a wave more so than an attribute of the wavetable as a
resource.  So -- I dunno.  Maybe better heads than mine can contribute some
opposing argument, but that's my initial reaction.

> sample looping parameters to be in the instruments instead of in the 
> wavetable, to allow dynamic manipulation.

This is probably only useful for making really weird sounds, but still I tend to
agree (being a weirdo myself).  This kind of falls under the "service provider"
view of the wavetable.  The loop parameters are attributes of the waveform (or
perhaps of the "instrument" if you're dealing with wave v. instrument mode --
but I digress), so it's natural to provide a "service" (in the form of a class
method or function callback) which changes them.  Most machines probably
wouldn't take advantage of it, but it could still be there (and such a method is
probably useful for interface design purposes anyway).

My 2 cents,
chris/hex/<uku>