Hi Fons, 2008/6/2 Fons Adriaensen <fons(a)kokkinizita.net>et>: I already roughed out some on this mailing list. Read this and think a little bit about it: The API has been designed around the typical use case where a generic audio source is processed in a series of subsequent stages (chain-like fashion, informally speaking) and then sent to a generic audio output. In this kind of applications sound processing is a marginal task, while encoding/decoding are not (and doing some work on audacious has made that quite clear to me). It's way better to keep those things separated IMO. Non prendertela a male e buona festa della repubblica, Stefano

2008/6/2 Fons Adriaensen <fons(a)kokkinizita.net>et>: It would work like this: stereo input -> hosts converts to 5.1 (the effect states it needs 6 channels) -> apply effect with 6 in channels and 6 out channels -> 5.1 output Nothing special as well. Stefano

Am Montag, 2. Juni 2008 schrieb Fons Adriaensen: @Stefano: Without having seen anything from your spec, when you don't allow different numbers of input- and output-channels your spec is absolutely worthless. Even the effects in mplayer (which is as far as I understand your mails your target as a media-player) can have 2-in and 6-out as far as I know from using it. LV2 might be to complicated because of all its possible extensions, but allowing for any number of inputs and any number of outputs of any type with a varying number of samples/events per instance-run is one of the things that seem to be crucial to plugins these days. Arnold -- visit http://www.arnoldarts.de/ --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a "rm -rf /". Or ask your administrator to do so...

On Mon, 2008-06-02 at 16:03 +0200, Stefano D'Angelo wrote: lets put it this way. the AudioUnit API includes a concept called a "graph" that is designed to let hosts do easy plugin chaining. there isn't a single noteworthy cross-platform host out that uses it, for two reasons: (a) its not cross-platform (b) every host has its own plugin abstraction already, and doesn't want to mess with trying to merge not just another plugin abstraction but a graph/interconnect/chaining one too. for what is worth, correct plugin chaining is pretty hard to do. ardour attempts to do this with LADSPA/VST/AudioUnit/LV2, and its really quite a difficult problem to get it right for all cases. what ardour does relies on mechanisms that some way outside of any of the above named plugin APIs, and are much more related to its internal signal processing model. if you tried to graft that code into some other host, my guess is that you'd have to completely reimplement it. --p

On Mon, 2008-06-02 at 16:49 +0200, Stefano D'Angelo wrote: so when a user decides to insert a plugin that has 2 inserts and 2 outputs in between 2 plugins that have 1 output and 1 input respectively, what do you propose to do with the signal? when a user adds a 1 input plugin after a plugin with 2 outputs, what do you propose to do with the signal? when a user deletes a 1 in/1out plugin from between a 1out and a 2in plugin, what do you propose do with the signal?

On Mon, 2008-06-02 at 20:11 +0200, Wolfgang Woehl wrote: sure, thats a good high level description of what ardour is doing. but think about what this actually means in practice: it means that your chaining logic is actually responsible for plugin instantiation (and destruction). a given plugin "unit" might have 1, 2 or more actual plugin instances within it. but if plugin instantiation is being done from within the chaining logic, how does it share code that the host might use that overlaps with this in some way?

On Tue, Jun 03, 2008 at 11:22:15PM +0200, Wolfgang Woehl wrote: I had the same 'gut reaction' when reading Paul's post. But it's by no means a simple thing. Remember that the plumber can't do his work in Jack's thread (since he has to do non RT-safe work), and 'users' (the Jack thread) will try to use the things being plumbed behind his back unless they are told not to. I've had similar problems in some clients that allow the user to reconfigure all or part of the processing in a more invasive way than just change a parameter value. The solution I adopted amounts to: 1. the main thread receives an event saying that processing has to be reconfigured (e.g. a user clicking a button). 2. It changes state and sends a message to the processing thread to bypass the processing (producing silence if there's no other alternative). 3. This message is seen in the next callback. The processing code changes state and sends a message to the main thread saying it's now safe to modify the processing chain. 4. The main thread receives this message, reconfigures the processing code, and when ready sends a message to Jack's thread to resume normal processing. 5. This message is seen in the next callback. The processing code changes state and sends a message back the the main thread. 6. The main thread receives this message and changes state to accept new reconfiguration requests. This can be simplified, e.g. the messages to the RT thread can just be flags that are set by the main thread and tested in the callback, and if the main thread has a periodic wakeup the same can be done with the replies. And most of this can be hidden inside the processing 'object' that is shared by the two contexts. But even then it remains somewhat invasive, requiring state management at both ends, and it won't be easy to hide all of it into a simple-to-use 'support library'. Which in the end means that anyone wanting to do this sort of thing should really understand what is involved, even if he/she doesn't have to write all the code to implement it. Which in turn means that it's probably a futile exercise to try and make it 'easy' to would-be programmers wanting to write the ultimate media player without even having an hint of how complex such a thing can be. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

2008/6/2 Arnold Krille <arnold(a)arnoldarts.de>de>: What about this: 5.1 stream and you have an effect doing low-pass filtering on one channel. You use 6 instances and you're done with it, and a clever host (not too much) could let you control their parameters together at the same time. (Anyway, I forgot to put the channel number on which to operate in the run() callback.) I take audacious as an example, here's a list of effects implemented for its API: - compressor - "crystalizer" - echo - time stretching and pitch shifting - voice removal - freeverb3 - pole-zero plot filter When you discuss something you usually listen. That's what I'm doing. Stefano

On Mon, Jun 02, 2008 at 03:58:48PM +0200, Stefano D'Angelo wrote: There are many ways to get a usable 5.1 signal from stereo, but this is not one of them. It's wrong on all accounts. If you build this into a host you can't even have a plugin that does it right. Unless you tell it to ignore everything but the L and R inputs which happen to be the the original stereo signal. In that case you could as well just give it those two signals, and not bother about the conversion. What is needed to do stereo to 5.1, or even to just play back 5.1 correctly depends on the actual (hardware) 5.1 system that you are driving. A system consisting of 5 small cubes and a sub needs different processing than one having 5 full range speakers. The required processing may be done in the amp, or not, in which case a plugin has to do it. And that's just 5.1. There's also stereo, 7.1, binaural, ambisonic, etc. A decent media player should be able to render any input format to whatever speaker setup the user has, and make the best of it. This is a very large number of conversions each of them can have many variations. Which is why you need plugins. LV2 would at least allow to have informative port names and types, and provide information to a host what they represent and how to use them. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.