Re:machine types as instrument abstractions, or IA-Machines

[ccastiglione]

I follow you _most_ of the way, but I'm confused about what exactly the
distinction is between an IA machine and any other machine.  Do you envision the
IA machine as purely a means for specifying an -- er, instrument useage policy
(for lack of a better phrase) -- and that then gets used by an audio generator? 
Or is "IA machine" just a term for an audio generator that uses the instrument
map?

The instrument map idea is great.  Something similar for envs maybe? :)  Or
maybe -- oo, here's an idea for you -- maybe env's should just be rolled up into
the category of "control signal" along with LFO's and be produced (if at all) by
machines designed specifically for that purpose.  Lots more flexible than having
a global env table, though of course your challenge now becomes how to map
waveforms (or instrument maps) to a specific control signal.  I guess that could
be done through the machine connect diagram hickimadoozie page (to use the
technical term).  But I can't wrap my head around it at the moment.

Hmmm...lots to chew on.

____________________Reply Separator____________________
Subject:    machine types as instrument abstractions, or IA-Machines
Author: "David O'Toole" <address@hidden>
Date:       3/13/01 3:47 PM

Interesting. Let me see if I understand what Ben is saying and see if I
can reconcile it with other suggestions. I think we can find a middle
ground that will let us do a lot of neat
stuff. Here is a possible scenario:

1. The Octal wavetable would be essentially a big bunch of buffers,
holding basic information about them: the wave data, wave sizes,
mono/stereo, loop-point, base pitch, fine tuning. This part is very
simple and has no instrument abstraction and very little policy. Some
machines could use it as-is.

2. A machine could represent a particular view of instrument abstraction
(an IA-Machine) by exporting stuff as Octal parameters. That is,
whatever the configurable details are for your new instrument
abstraction, export them as parameters that the user can interactively
control via widgets, script via automations, or save as plaintext
"patches".

3. The only snag is that an IA-Machine will need some way to select a
wave number based on the velocity and pitch of a note (or other keys).
An easy solution would be to call a function like I described before: 

-----
wave_info *basic_map(int mapID, param note_key, param velocity_key,
param user_key);
-----

What is "mapID"? A wavetable map would be a global resource. Instead of
choosing a particular wave-number to play on a channel, an IA-Machine
user would select a MAP instead. This would feel like the wave number
column in a Buzz machine, except it's selecting a whole map that may be
choosing many sounds. Probably only a few machines would actually select
wave numbers directly.  

Basically a map would be a little table using its keys to select
different waves. In the case of a JeskolaTracker IA-Machine, you could
use a map that simply maps the note_key into the corresponding wave
number (i.e. the map wouldn't do much.) In a violin emulator of some
kind, where each kind of stroke/pluck might have a different wave, the
user_key could be used to select the type. 

I like this because it seems very flexible. Consider:

1. The instrument config interface is already written if we do it this
way
2. Two machines could use the same sample map but different configs 
3. Configs for IA-Machines could be saved and swapped or copied
4. We're not stuck with one instrument abstraction that has to satisfy
everyone
5. We could have new and wacky IA-Machines coming out all the time,
while a more traditional one with common ideas would be a trusty
workhorse (just as jeskola tracker provided a familiar sample-based
tracker interface on top of Buzz, and then all the weirdo stuff came out
later :-)
6. It's very simple to program on the host side :-) but seriously
though, I think machine authors are probably the best people to decide
what machine abstractions are around, and if we can do this in a
configurable way with IA-Machines, then there will be a lot of room for
experimentation. Also, the less code there is in the host (Octal
itself), the more easy it will be to port. 

What does everyone think? This seems to incorporate Ben's ideas about
instrument types being pluggable. It also seems to capture what Chris
was saying about maps and envelopes being global resources (that
MIDI-mapping bit was a very good point) and also his interest in the
"sample/instrument modes in impulsetracker" idea, where you have varying
levels of sophistication in an instrument abstraction. Basically we
could have IA-Machines of varying complexity. I think your ideas go
together.

I'd love any feedback people can give.... this seems like a nice and
flexible way to implement it. 

> 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


I guess we could say that an IA-Machine is free to ignore certain parts
of the basic wave_info, and just use its own values for loop point. You
don't want to override the wave length, though, as you'll certainly
segfault :-)

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


_______________________________________________
Octal-dev mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/octal-dev