Re: [LAD] jack session compatible applications?
how about Yoshimi, AMsynth, Ghostess ? i know for a fact that these apps support JS, but i'm not involved in the development so it's probably not up to me to add them to the list (+ i'm not sure in what version JS was introduced) grtz Thijs 2011/9/22 Nick Copeland nickycopel...@hotmail.com Date: Thu, 22 Sep 2011 11:36:34 +0200 From: ro...@gareus.org On 09/22/2011 10:22 AM, m.wolkst...@gmx.de wrote: Am Sat, 17 Sep 2011 19:29:32 +0200 upgraded (added xjadeo). Added Bristol = 0.60.6 ## apps supporting jack-session (09/22/2011) ## # sorted by name * ardour 3 (jack session participant) * bristol = 0.60.6 (jack session participant) * guitarix * gxtuner * hydrogen0.9.6svnHEAD (jack session participant) * jass (jack session participant) * qjackctl = 0.3.7 (as jack-session manager) * qtractor = 0.4.6 (as jack-session participant) * xjadeo = 0.6.1 (jack session participant) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- follow me on my Audio Linux blog http://audio-and-linux.blogspot.com/ ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] jack session compatible applications?
On 09/26/2011 09:21 AM, thijs van severen wrote: how about Yoshimi, AMsynth, Ghostess ? Yoshimi: since 0.060. amSynth 1.3: the 1.3 beta's have JS support. Best, Jeremy ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS to Ingen: VC to PCM
On Sun, Sep 25, 2011 at 06:20:22PM -0400, David Robillard wrote: In particular, synth plugins (VCOs, VCFs, etc.) are fundamentally different from general audio processing ones (EQ, dynamics, etc.). This doesn't exclude the possibility that some may be useful in both contexts. Yes, but many, if not most, are usable in both contexts. Filters of any variety are the best examples. I'd contest the 'most'. Can you give any more examples ? For filters, only 'static' ones (only GUI controls, same processing on all channels or voices) could be used in both contexts. Once any parameter becomes per voice and 'voltage controlled' the similarity ends. And even the purely static ones you'd want to schedule differently. On a mixer you typically have a lot of channel strips, each of them in most cases a linear chain of processing units. It makes sense to keep the elements of such chains together and schedule them on the same worker thread. In a polyphonic setting voices are independent, typical patches are not linear, and it makes much more sense to schedule per voice. A universal plugin standard should support these different modes, which means separating common and per voice/channel parts. Even if it does I would not expect any particular plugin to support both modes. You can probably get a better plugin by designing it for a specific application. A tricky one no one has yet tackled (anywhere) AFAIK. Because if you start to analyse these things (and there are many more aspects to it) it becomes clear that current plugin standards completely ignore all of this, they get in the way rather than provide the necessary hooks, and you better start from zero. Just consider the following list: - 'Voltage control' - MIDI control - OSC control - Save/restore settings - Automation Traditionally a host will try to do any of them using only the set of 'control ports' exposed by a plugin, or by hooking into the GUI - DSP communication if the plugin has its own GUI. But the requirements for each of these are quite different and usually in conflict. There is much more to it than some metadata. I think there is more overlap between these cases than this implies, or at least can be. A polyphonic synth *could* have a very large portion of the processing time be common shared data. As long as voices are independent there isn't much to share except e.g. big lookup tables as used in some oscillators. Even if the host replicates the plugin for each voice (which it could do) you'd want the instances to share such data. Which again requires some support from the plugin standard. There is another thing missing in current synthesis hosts (AMS, and AFAIK also Ingen): an explicit definition of the point where a polyphonic patch mixes its voices into a single audio signal. Some processing should be done after this point, e.g. reverb and some other effects. So if you do this in a plugin, it becomes 'polyphonic' at one side, and 'multichannel' at the other. Some more metadata required... Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] jack session compatible applications?
On 26 September 2011 08:43, Jeremy Jongepier jer...@autostatic.com wrote: On 09/26/2011 09:21 AM, thijs van severen wrote: how about Yoshimi, AMsynth, Ghostess ? Yoshimi: since 0.060. amSynth 1.3: the 1.3 beta's have JS support. BTW, I've just created an Arch Linux AUR PKGBUILD for amsynth-svn: https://aur.archlinux.org/packages.php?ID=52689 It's my first PKGBUILD, and is based on a combination of amsynth and aqualung-svn PKGBUILDS. Haven't read docs. Cheers, James. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
2011/9/26 David Robillard d...@drobilla.net: Here is a quick extension for CV Ports, i.e. audio ports with control semantics: http://lv2plug.in/ns/ext/cv-port/ Argh sorry for not having followed the discussion when it took place, but I have to say I really dislike this extension. The problem is that it can easily go against the graceful degrading configuration concept of LV2. E.g., suppose writing a varispeed plugin that takes the amount of delay as a control input - you will end up writing two versions, one using CV ports and another using normal control ports, if you want to support both kinds of hosts. IMO it could be better done like this: cv:CVPort to be a subclass of lv2:ControlPort and a feature URI to be defined. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS to Ingen: VC to PCM
On 26/09/11 05:08 AM, Fons Adriaensen wrote: On Sun, Sep 25, 2011 at 06:20:22PM -0400, David Robillard wrote: In particular, synth plugins (VCOs, VCFs, etc.) are fundamentally different from general audio processing ones (EQ, dynamics, etc.). This doesn't exclude the possibility that some may be useful in both contexts. Yes, but many, if not most, are usable in both contexts. Filters of any variety are the best examples. I'd contest the 'most'. Can you give any more examples ? For filters, only 'static' ones (only GUI controls, same processing on all channels or voices) could be used in both contexts. Once any parameter becomes per voice and 'voltage controlled' the similarity ends. I am not considering per voice at all since we don't have that technology anyway. Once any parameter becomes 'voltage controlled'... It's still a parameter a user might want to set manually if it's not being voltage controlled, and it's still a parameter that should be presented sensibly in a non-modular host like a DAW or effects rack. Because if you start to analyse these things (and there are many more aspects to it) it becomes clear that current plugin standards completely ignore all of this, they get in the way rather than provide the necessary hooks, and you better start from zero. Just consider the following list: - 'Voltage control' - MIDI control - OSC control - Save/restore settings - Automation Traditionally a host will try to do any of them using only the set of 'control ports' exposed by a plugin, or by hooking into the GUI- DSP communication if the plugin has its own GUI. But the requirements for each of these are quite different and usually in conflict. MIDI and OSC are more or less logistically equivalent. There are only really two fundamentally different things here with respect to how the plugin itself works: control via messages (MIDI/OSC) and control via signals (voltage control). I think there is more overlap between these cases than this implies, or at least can be. A polyphonic synth *could* have a very large portion of the processing time be common shared data. As long as voices are independent there isn't much to share except e.g. big lookup tables as used in some oscillators. Even if the host replicates the plugin for each voice (which it could do) you'd want the instances to share such data. Which again requires some support from the plugin standard. Right. There is another thing missing in current synthesis hosts (AMS, and AFAIK also Ingen): an explicit definition of the point where a polyphonic patch mixes its voices into a single audio signal. Some processing should be done after this point, e.g. reverb and some other effects. So if you do this in a plugin, it becomes 'polyphonic' at one side, and 'multichannel' at the other. Some more metadata required... Ingen allows the user to set each module as either polyphonic or not. Mixing down is done wherever necessary (i.e. wherever a poly output is connected to a mono input). I think maybe this is a bit more fine grained than is useful though, and have considered having a single well-defined (internal) module that mixes down as you've described, or maybe just not allowing poly and mono in a single patch at all... Making sure things like reverb etc. are put after the polyphonic stuff is a user decision in either case, though. With respect to plugins, supporting poly/multichannel would inherently be a per-port thing, i.e. specific port(s) would be labeled as polyphonic, or multi-channel, so I don't think such a plugin would cause any trouble. -dr Ciao, ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
On 26/09/11 06:22 AM, Stefano D'Angelo wrote: 2011/9/26 David Robillardd...@drobilla.net: Here is a quick extension for CV Ports, i.e. audio ports with control semantics: http://lv2plug.in/ns/ext/cv-port/ Argh sorry for not having followed the discussion when it took place, but I have to say I really dislike this extension. Meh, no big deal, it's just a draft. Those big red letters aren't for nothing. :) The problem is that it can easily go against the graceful degrading configuration concept of LV2. E.g., suppose writing a varispeed plugin that takes the amount of delay as a control input - you will end up writing two versions, one using CV ports and another using normal control ports, if you want to support both kinds of hosts. or just don't, and expect hosts to implement this trivial extension. Backwards compatibility would be nice though... IMO it could be better done like this: cv:CVPort to be a subclass of lv2:ControlPort and a feature URI to be defined. I suppose this could work, since theoretically the port is still connected to a buffer with a single float as lv2:ControlPort dictates. Subclass is academic since most hosts don't care anyway, the port would have to literally have both types listed. The only way for this to be feasible is if the host supports said feature, it guarantees that such ports will ALWAYS be connected to a full audio-rate buffer (otherwise you need some mechanism to say which it's connected to and things get too complex). This is slightly more complex, but not too bad, and only complex for hosts that support CV... good idea. pedantry It's debatable whether or not this violates the spec: Hosts that do not support a specific port class MUST NOT instantiate the plugin, unless that port has the connectionOptional property set This is ambiguous. We might want to reword that slightly in the next revision to explicitly state that hosts can instantiate if they understand *some subset* of the port types that describes a port type they support, i.e. unknown additional types can be ignored. This implies new port types can't modify the definition of others, which is good and should be explicit anyway. /pedantry -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS to Ingen: VC to PCM
On Sun, Sep 25, 2011 at 10:01 PM, David Robillard d...@drobilla.net wrote: On Sun, 2011-09-25 at 14:28 +0100, Aurélien Leblond wrote: 1. Audio in/out ports. These are just blocks of samples, same as e.g. Jack buffers. Some call this 'PCM' but that is a misnomer. 2. Control in/out ports. These are technically identical to audio ports (full sample rate), but the signals carried on them are normally not meant to be audio. How they are interpreted depends on the module and the particular port. Frequency control inputs can be linear or log, in the latter case that means 1/octave. Gain controls can be linear or log, there is AFAIK no fixed conversion factor for the latter. For example the VCA module uses 80dB/1 in exponential mode, but other gain controls may be different. Control ports are audio rate, but most modules/plugins subsample some or most of them. They either just use the first value in a block, or recompute internal paramters based on the last value in a block and then interpolate them linearly. Since control signals are (at least officially) at audio rate, LADPSPA plugins designed to be used in AMS (e.g. mine) will declare their control inputs as audio inputs. Thanks, I think it makes things way clearer! What's confusing me so far is that I ported the VCO2 module, but with exactly the same setup, the VCO2 LV2 in Ingen sounds out of tune compared to the one in AMS. I thought it was due to some kind of needed convertion, but maybe I'll go back to my code to double check I didn't make any mistakes! The note builtin in Ingen uses Hz for frequency. Anything else is completely insane :) There is a converter plugin in 'omins' which I need to port to LV2 as well one of these days... Hi David, Could you let me know where in Omins it is? I can port this for you... One plugin to create won't kill me (and I start to enjoy it anyway!) Aurélien ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS to Ingen: VC to PCM
On 09/26/2011 03:37 PM, Aurélien Leblond wrote: Hi David, Could you let me know where in Omins it is? Well, not David, but: http://svn.drobilla.net/lad/trunk/omins/src/hz_voct_4200.c -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS to Ingen: VC to PCM
Hi David, Could you let me know where in Omins it is? I can port this for you... One plugin to create won't kill me (and I start to enjoy it anyway!) Aurélien ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev Just watch out, some of them are really crappy (cough, the ones coded by me. cough.) ;) Loki ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
2011/9/26 David Robillard d...@drobilla.net: pedantry It's debatable whether or not this violates the spec: Hosts that do not support a specific port class MUST NOT instantiate the plugin, unless that port has the connectionOptional property set This is ambiguous. We might want to reword that slightly in the next revision to explicitly state that hosts can instantiate if they understand *some subset* of the port types that describes a port type they support, i.e. unknown additional types can be ignored. This implies new port types can't modify the definition of others, which is good and should be explicit anyway. /pedantry useless-rant This is IMO unfortunate of the LV2 spec, a host does not only have to check for supported features, but also go through all ports and check type and connectionOptional. We could just have features for port types defined in extensions... /useless-rant Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
On Mon, 2011-09-26 at 09:27 -0400, David Robillard wrote: On 26/09/11 06:22 AM, Stefano D'Angelo wrote: [...] IMO it could be better done like this: cv:CVPort to be a subclass of lv2:ControlPort and a feature URI to be defined. [...] The only way for this to be feasible is if the host supports said feature, it guarantees that such ports will ALWAYS be connected to a full audio-rate buffer (otherwise you need some mechanism to say which it's connected to and things get too complex). Actually, on second thought, while I dislike making anything at all complex for this ostensibly simple functionality, I think if a feature is going to be involved anyway it might be best to allow the host to explicitly specify which type each port is connected to. Since this is intended for modular hosts, the host would typically inform the plugin which based on what the port is connected to. The feature would basically allow the plugin to expose an additional function which the host could call to inform the plugin if the CV port is connected to control or audio data. The cost is complexity in the plugin, namely a CV supporting plugin would have to keep a type flag around for all CV ports to know which it is connected to (a simple macro or inline function can make the actual reading simple). This incurs a minor branch cost (one per CV port per cycle). Thoughts? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
