Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
From: Benno Senoner (sbenno_AT_gardena.net)
Date: pe syys   24 1999 - 08:45:25 EDT


On Thu, 23 Sep 1999, David Olofson wrote:
> On Thu, 23 Sep 1999, Benno Senoner wrote:
> [...]
> >
> > Agreed, I like this idea,
> > for example the volume-slider (the GUI part) of a gain-control plugin just
> > installs an event-sending port and sends the events to the plugin DSP code.
> > Plus the DSP code installs an event-sending port and connect the event-receiver
> > port of the volume-slider.
> > That means if someone (a sequencer/ or arbitrary plugin) changes the gain value,
> > the fader would move automagically in the correct position.
> > Or is this suboptimal ?
>
> Well, with the event system I'm working on is based on Recieve Ports only. That
> is, you don't write all your events with destination addresses to a single
> output buffer for dispatching by the engine, as in the design I might have
> mentioned earlier. (Perhaps I'll move back to that kind of design, but I'd
> really like some realistic processing net models with traffic statistics first.)
>
>
> There's one trick that *could* be done at virtually no cost though -
> sending the same buffer to multiple recipients. What I'm getting at is this: If
> the DSP <-> GUI communication is based on the two sending events directly to
> each other's event ports, the automation system could tap data from those
> communication paths by scanning the GUI -> DSP buffers for input, and sending
> it's output to both the GUI and the DSP code.

Yes this seems ok to me,
bt I want a generalized system where every other process can be the
"automation".
In short, I wat that my own process is able to get parameter-changes
notifications from the engine, and is allowed to send parameter-changes to any
plugin. (with immediate reflection on the GUI sliders, other
automation-recorders etc).

what about the following scenario:
sequencer1 continuously changes the cutoff frequency of a LP filter-plugin,
the GUI slider moves reflecting the changes.
sequencer2 records the automation parameters.
If the user moves the GUI sliders manually sequencer2 can record the data too.

>
> Not a hardware problem, but what I have in mind isn't really networking - it's
> about building clusters using 100 MB or gigabit ethernet with RTLinux RT
> communication drivers. More like extending connecting the machines into
> something like a huge SMP box, than building a network...

Ok in a dedicated enviroment running at 100Mbit or 1Gbit , if there is no
additional random network traffic, IMHO using simple UDP/IP with SCHED_FIFO
processes you can reach a <20-30ms latency for your needs.

>>
> <legal stuff>
> Speaking of Qt; I came up with an interesting licencing problem a while ago.
.....
> or perhaps didn't even know that something like that could be written. Does
> that mean that the end user - by loading a closed source plug-in from a
> developer without a Qt developer's license on the Qt host - is guilty of
> breaking the QPL?
> </legal stuff>

I think as long as the Qt-host is opensource , or the Qt-host creator owns a
license there should be no problem, but I'm not 100% sure about this.

regards,
Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST