Re: sampler

[ben]

> >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.

That sounds better.  I wouldn't have any problems managing Octal songs
as directories, but inline storage would be better for distribution.

> >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.

Yes, the wavetable would be a global resource for machines to use as
they please.  As I was thinking of it, an 'Instrument'
(ImpulseTracker-style instrument) would simply be one of those machines.
It would access the wavetable like anyone else and facilitate polyphony,
pan/vol envelopes, etc.  Of course, other machines that used the
wavetable could exist, e.g. a drum machine tone bank.  The Instrument
machine I was thinking of would just be the basic sample-playing
machine, with nice extra features.  Maybe as a default setup (on
creation) each instrument machine could act like a sample in IT's sample
mode.

> 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 haven't really used Buzz, but that's an interesting method.  So
envelopes are basically globally accessible like the wavetable?

> 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.

Right, only the most generic parameters (essentially, just the sample,
index/name, and middle-c rate) would be actually in the wavetable.  NNAs, etc.
would be in the machines.

> > 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

Yeah, that's what I was thinking. :)  I remember messing around with
loop points in IT and thinking it would be neat to be able to do that in
the song. :)

-ben