[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sampler
From: |
ben |
Subject: |
Re: sampler |
Date: |
Tue Mar 13 13:24:02 2001 |
User-agent: |
Mutt/1.2.5i |
> >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