Per channel stereo outputs (multi-channel support)

[danvd]

Hi Harry!

Do you plan to add per-sample audio out ports? Instead of implementing internal effects, one can route each sample to host's bus and apply effects here :)

Regards, Andrew.

[harryhaaren]

Hi @danvd,

Adding per-sample audio outputs to a plugin makes it unusable in most hosts (Ardour / QTractor etc ). Ardour will load them, but having a 18 output plugin, Ardour cannot apply FX to just one of those channels. AKA, its just not practical, even though in theory its a good solution.

Although per-pad FX (or more accuratly "per-voice") are a bit of work to implement, they're the only way to actually achieve the desired workflow.

Thanks for the suggestion though! -Harry

[danvd]

Hi @harryhaaren Ok, thanks for fast answer :). As for - no, ardour can make this. Route needed channel to a new bus and you are done (and bypass multichannel panner). Anyway, I'll fork your project and then make these changes if you don't mind :)

Regards, Andrew

[harryhaaren]

@danvd, fair point: I hadn't considered routing that way. A Bus is necessary per sample though right? One 16 channel bus isn't any better: Ardour won't know how to apply a stereo FX to a 16 channel bus?

Thinking about workflow, its much nicer to have pads / fx integrated in one UI, and automation running on the same track in order to create music. Having 16+ tracks (Fabla 2.0 will have 4 banks too!) all running into busses, and then adding some of the same compressor / FX to 4-6 of those tracks... its a lot of unnecessary work.

Routing like this is what per-sample outputs will achive:

On the other hand, Fabla 2.0 with integrated FX will have a much faster + more integrated workflow:

Don't you think its a lot of work setting up the busses every time? I know, Ardour template: but realistically your kicks / hats / snares will be in different locations on the pads, so your Ardour connections will be different too... :/

Welcoming your opinion on the above, perhaps there's an oversight on my part?

[danvd]

@harryhaaren Wow! You are very quick, and images are great! But! The main reason to have multichannel is to make 1 midi track with one fabla instance and then route it's channels to different busses. As for me, 3 or 4 busses will be just enough for this. Buss drum to 1st bus, hats and claps/snares to second and then these 2 busses to 3rd with compressor... Instead of drawing, here is my videos of Yoshimi lv2 plugin, where I've already done this: Links to youtube:

Ardour: http://youtu.be/e_YnqGksXF8 MusE2: http://youtu.be/bUL0_0XlMwY

On the other hand, internal efx is a good thing, but I more like to use complex plugins (like compressors, EQs..) in host.

/Andrew

[harryhaaren]

@danvd, right so I like your workflow, just not how you're currently achieving it..

If there was a "use-case" type LV2 extension to allow a plugin integrate with a host not on a per-audio-track basis, but on a per-use-case (or per-bus) then this could be achieved transparently to the user. That would be cool! Back to reality, hosts currently don't currently support that idea, so never mind.

Can I ask why you don't like integrated FX? They'll be more flexible than you can achieve with your bus system, since the delay / reverb sends and delay sends will be "triggered" automation. This is really difficult to explain... but its awesome. An example.

A roll of repeating snares, and you want to add some delay to individual hits, not all of them.

• Per-output: you need 2 samples loaded beside each other, one with the delays, one without. You must trigger a different MIDI note in order to have the delayed version triggered.
• Integrated: the control-port value is "sampled" at the time of a note-on event. This means that every note can have a unique combination of delay / reverb / FX.

Integrating FX to the voice level, instead of the sample level adds another layer of functionality and power.

Again, opinion please? -Harry

[harryhaaren]

PS: in particular this is very interesting for the Retriggering of voices after they've started playing: ideal for glitch and breakbeat-chaos!

[danvd]

@harryhaaren ,

<If there was a "use-case" type LV2 extension to allow a plugin integrate with a host not on a per-audio-track basis, but on a per-use-case (or per-bus) then this could be achieved transparently to the user. > If I correctly understand, this is like Cubase SX+ where we have vst instruments pane and tracks, where we use these instrument's instances. That's right?

About a roll of repeating snares with per-note effects: Yes, I agree, that internal FX is the best for this task. All Reverb/Deleay parameters are tuned in lv2 plugin, and host is only responsible of turning FX on or off at concrete period of time. But this task is rather rare (may be I'm wrong) and It's achived with host's busses in the same manner. For example - we can route snare sample output to dedicated bus, attach insert effect to this bus (Reverb or Delay), tune effect's parameters and then turn it on or off via bus track's automation. Yes, there will be a need in separate bus track for this, but it's the only drawback.

And another example: what about sidechain effects like compressors? Internally, if plugin has only stereo mixed output, it more hard to achieve (or simply impossible if there is no audio input port in plugin) than in multioutput case.

P.S. The idea of multichannel plugins my be not a perfect one, but it helps a lot to port songs, made in cubase years ago to linux audio environment more easyly. I have some songs where 'reason' and 'batery' was used, that's why I like to see this functionaly in your lv2 drum sampler :). This is another argument to multi-output version.

I didn't mention how I supposed to implement this - there should be 2 records in ttl file - one with mix+multiout audio ports and another with mix only, so user can choose beetween them without any problems.

P.P.S. May be you open this issue again until our debates are over? :)

/Andrew

[harryhaaren]

Reopening due to request to do so until discussion is somewhat concluded: thanks for requesting @danvd.

Note I've requested input from people on IRC in #ardour #lad and #opensourcemusicians on irc.freenode.net. If you feel so inclined, do just us there too. I will try summarize the points brought up there, and note them here for reference.

[danvd]

@harryhaaren, I'm monitoring discussion on #ardour channel now and it's became clear for me what you said about per-note FX. I agree, that it's hard to make with host's busses approach. Bat again, how often this will be used?

[harryhaaren]

@danvd, its a pretty genre-based technique: I don't know what music you make, but glitch-hop, breakbeats and drum-n-bass use per-note FX extensively.

I admit I'm a bit of a Glitch-Hop Dubstep DnB fan, and I find it very difficult to make that type of music with a workflow that is fast enough to stay creative.

[danvd]

@harryhaaren, some time ago I made simple pop-like music and did not dive into DnB style, so that's why I don't know how often this technique is used. It seams, that per-note fx is more tracker-like way to make music, like in old spectrum trackers, buzz tracker and modern renoise, where each note can have lots of various parameters..

My way of thinking is more multitrack sequencer-like, so may be it's the main reason why you don't like this idea. Anyway, I'll make it in my fork, and if you like it I'll be glad to see this in your original Fabla project.

Regards, Andrew

[harryhaaren]

@danvd, Feel free to fork Fabla, but please change the visuals of the user-interface to avoid confusion for users. Also please use your own URI / email to identify the plugin.

Keep in touch, if you have any questions about the code then feel free to email me directly: harryhaaren@gmail.com. Cheers, -Harry

[harryhaaren]

As promised, a summary of the discussion on IRC, in the #ardour room on irc.freenode.net.

• tl;dr;
  • Per-note-FX cannot be achieved without the plugin having the FX built-in.
  • Per-pad-outputs makes a user actively engage in routing the output of the plugin.
  • MIDI CC events should be used to control per-note FX as they are sample accurate (and control ports are not).
  • The simplest workable solution seems to be per-note-FX, and including midi:binding information so users know what MIDI CCs control what features of the plugin.

Summary of IRC in #ardour on freenode.net

• Paul Davis (Ardour author)
  • Fabla as plugin inside modular host like Ingen. Offers flexible routing without paying attention to tracks / busses.
  • I think it is a fundamental mistake to make the user have to think about this stuff (this referring to routing)
  • Noted that LinuxSampler has a 32-output version of the LV2 plugin.
  • Multiple instances of a plugin on seperate tracks as a solution to the FX problem (possibly sharing sample-memory between instances?) FX applied "per-instance", which also means "per-track", as each instance has its own track.
  • If a DAW host actively supports I don't know if this addresses all of the issues around per-pad outputs or not, but it would certainly be easy to use and extremely handy for when you want
• David Robillard (LV2 project)
  • Using control ports and 'sampling' the value is bad, the timing depends on the blocksize of the run() callback
  • Using MIDI CC messages (which arrive with sample-accurate timting) solves this issue.
  • How would users know CC num 42 controls feature X of the plugin?
  • Some vocab exists midi:binding which describes any MIDI controller
• Robin Gareus (Ardour + LV2 contributer)
  • Lots of input as a whole
  • MIDI CC is sample accurate, while control port values are not
  • Suggestions on (in longer term future) enabling multi-port outputs, and hosts mixing down the buffers to stereo.
  • the host should be improved to honor LV2 audio-port groups and properties

I (Harry of the OpenAV project) would like to thank all those on IRC for their time and insight.

[danvd]

@harryhaaren Thanks for spending time for this discussion! Now I'm sure that Fabla should have internal efx for per-note use and on the other hand, optional per-sample outputs+ several group outputs exposed to host to make it please everyone. I'll simply make my own copy (not a fork) of Fabla and make my changes only for myself to not confuse anyone else.

Regards, Andrew

[harryhaaren]

@danvd, I'm glad this discussion took place too: its verified the need for all of the features discussed, and paved the path to actually achieving them. Thanks for not publicly releasing a multi-out version, and know there is ongoing work to provide the proposed Lv2:AudioGroup output busses for Fabla 2.0.

Cheers, -Harry

[rhetr]

@danvd, this is something i asked about a year ago: https://github.com/harryhaaren/openAV-Fabla/issues/17 and would like to see implemented as well.

I understand the desire to simplify routing but I want to be able to mix all drums in the same context as other channels (ie in the same mixer). I don't see why an lv2 extension for output busses should be necessary, it makes more sense to me to include useful information in the existing jack_metadata and encourage hosts to intelligently handle that information. e.g. ardour could read fabla's output ports and instead of having 1 track be 18 channels it could split them into 9 separate stereo channels. This is roughly how ableton live does it with their drum rack plugin.

personally i use carla and you're right, routing that many channels manually is a pain, but i think the solution isn't to try to restrict access to the channels themselves to just an lv2 extension but rather to improve the workflow regarding ambiguous output ports.

in any case danvd i'd appreciate if you did fork fabla for multi-outs because i would like to use that as well.

[harryhaaren]

@rhetr , i think you misunderstand the workflow that the LV2 extension will provide: they are outputs, but rather than having 16 * 4 * 2 = 128 outputs (16 pads, 4 banks, stereo), there will be 4 stereo sub-mix outs.

These sub-mixes will be created inside Fabla 2.0, and hence also saved with your presets. If you want to move from Ardour to QTractor / JALV with a complex routing like 128 outputs and manually routed, you're tied to just that host, and there's no way around that.

There was another discussion about implementing this on #ardour on irc.freenode.net last night, and the end conclusion is that for drum type sounds, the workflow proposed for Fabla 2.0 is the easiest and scales best.

If the issue you have is that 4 busses is too limited, please let me know. If you genuinely think per-pad outputs are better, then please illustrate why, and how much manual work you're expecting to have to do.

Cheers, -Harry

PS: I'll re-open this issue for the sake of discussion.

[danvd]

Hi @harryhaaren!

Since this issue is still open, I can say, that I made multi out patch some time ago. Applying it to current git master (after a commit made on Nov 4 2014) will bring 34 mono (18 stereo) outputs, i.e - 1 stereo mix + 16 stereo outputs (one per channel). The final channel map will be:

1. L+R - Stereo mix (as before) (with compressor effect)
2. L+R - Channel 1
3. L+R - Channel 2 etc.. All individual channels are exported without compressor applyed, only final mix will use it. Here is a link to a sample melody made with multi channel Fabla: http://youtu.be/AMklg13KI8Q Only 5 samples are used. They are routed to individial host busses. Bass drum + clap are routed to control input of sidechain compressor (for compressing bass), Hat is routed to a delay line. Clap is also routed to another delay line.

I've created new pull request, it's up to you, Harry merge it or not, but anyway, may be this patch will be useful for somebody. Here is the link to request: https://github.com/harryhaaren/openAV-Fabla/pull/39

Regards, Andrew.

[harryhaaren]

Hi Andrew,

Thanks for posting the patch, indeed some users might wish to build this version themselves.

I won't merge this: and it is because this is not backwards compatible. Some hosts do not handle anything except mono or stereo out: I'm sure you would agree breaking backwards compatibility for these hosts is a bad idea.

PACKAGERS: please do NOT package this: it breaks backwards compatibility.

I'll close this issue now. Thanks for your contribution to Fabla, I'm happy to refer any users who ask for this feature to your patch. Please do not release or package your patch, as it breaks backwards compatibility with the existing released Fabla.

Fabla2 will fix the issue busses, so a fix is on the way. Thanks again, -Harry

PS: Nice music in the video!

[ViktorNova]

Just wanted to chime in and say thank you to @danvd for putting this patch up - I will definitely be merging it into a branch of one of my forks and using it in the studio!

To add my story to the conversation - my band has been using Fabla 1 live (currently have 6 global instances running at all times, for each song) and are now in the studio working on the album, so I need an individual stereo wave render for each drum sample - I don't even need to explain why multi-out is needed in this situation =)

[harryhaaren]

Hi @ViktorNova, cool I'm happy Fabla is useful for you, and also that Dan posted his patches - the beauty of open source :)

Do you have any videos of what you're using Fabla for live? I'd like to see! -Harry

[ViktorNova]

Hey @harryhaaren , thanks for asking! Sadly no videos yet, but I will share them with you as soon as we get some =D