Re: Re:sampler

[David O'Toole]

> 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

I tend to agree---not allowing embedded waves will make the songs more
"brittle". It's already kind of a tough situation in case you lose a
machine, but the web repository should help that. But having a song
become messed up because you moved or lost one part of your sample
library is a real problem. The "project file" needs to be kind of a
unit. External waves should still be allowable of course. 

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

Yeah. Sometimes you want a very simple sample player or looper (for
background sounds, ambient noise, little drum sounds) and sometimes you
want something capable of doing a lead sound. So basically a sample and
instrument have an integer ID, and switching between modes will turn on
the extra features? How do you all feel about that. 

I'd already been thinking about having more than one interface to the
wavetable, sort of like this:

wave_info *get_wave_info(int id)
as well as wave_info *get_instrument_wave(int ID, param note_played,
param velocity);

We can choose the wave either by its ID, or choose an instrument by a
function accepting note and velocity info that can actually select other
waves with different info. We should have a discussion soon on what
attributes should be in the wavetable for instruments.... that way
anyone who wants to work on Gearlib with Luka can implement functions to
read that information and resample waves, apply envelopes, etc.

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

Yeah, that way one machine can be a tiny sample player that just plays
them and doesn't even resample (I will probably write one as an example)
another can be a sampler machine that respects instrument attributes.
I'm also working on ideas for a possible HD-playback machine (for vocal
remixes and even doing completely non-electronic music with Octal.) 

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

Wow, I didn't know that's how it worked. I've never been able to figure
out what all the controls do on that page, other than volume envelopes
and loop points. Neat. 

> 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 

Yeah. I should really talk to luka and put together a little blurb about
what his Gearlib idea is supposed to be. Basically a library of common
DSP functions and stuff so that writing wavetable machines becomes
easier. The wavetable stores instrument attributes, but the machines and
Gearlib interpret what it means sonically. 

-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal