[linux-audio-dev] XAP again - channels, etc.

[torbenh at gmx.de]

On Mon, Mar 24, 2003 at 03:08:12PM -0800, Tim Hockin wrote:
> Interesting stuff worth talking about.
> 
> > Is this a clean, natural division? I don't think so. Why does the
> > model treat the output of an envelope generator as being (in many
> > respects) more like a string than it is like an oscillator output?
> > Why isn't it clear what an LFO's output type should be? Why does
> > something as simple as a ramp spawn so much complexity?
> 
> Some good questions.  In fact, maybe an LFO _should_ be audio data.  Or at
> least Audio-rate.  But one can argue that an LFO is LF enough that you can
> represent it reasonably well with a series of short linear ramps, and have
> less overhead.  

yes... but it still represents an audiorate signal, whether it is a
stream of events or not. 

i like the idea of having a stream, and interrupting code.
audio is the stream and then there is timestamped control data
interrupting the stream. but the user changing the graph is interrupting
the whole graph.

hmmm... dont know how to explain this better. hope you get it.

> 
> Maybe XAP should consider some method of identifying Audio-rate control
> ports.  If your control expects audio-rate input, you should be able to ask
> for it?  Why not use actual audio ports for that, then, and just hint that
> they are control signals?  An envelope generator or an LFO should be audio
> outputs that go into audio inputs.  Maybe.

I would rather try to build a class hierarchy for ports...
in galan a port type is only an interface.

only push and pull semantics should be handled nicely but i think simon
knows the answer.

> 
> 
> > Even where the audio/event distinction looks clear cut, its not. The
> > user toggles a switch. Thats an event, surely? Wellll... maybe it is,
> > but then, what does the plugin do with the event? If the switch is
> 
> > switch *is* an event. But the rise and fall characteristics should
> > belong to the owner of the source, not to the destination. An app
> 
> Disagree, here.  The flip of a switch is a binary event.  The receiver needs
> to handle it.  Non-binary things like knob turns will already either be
> interpolated by the sequencer, by a custom UI, or by the plugin.  Or all
> three.

yeah you are right.
the switch can not know what type its output will be converted too, so you
can not provide all typecast params.... 

i think we need parameterized typecasts.

a cast from Event/Binary to Signal/Norm needs a parameter.

in galan the signal to event converter needs to be fed by a clock also.

i am not sure how to model this correctly but an implicit typecast must
be configured somehow.


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language