Fabla 2.0 Wishlist

[ViktorNova]

A major thing missing from Fabla is having a filter on each pad

A switchable hi/low pass filter would do the trick, although having one of each with resonance would be ideal! Maybe plop in the upcoming new version of Filta? =D

[harryhaaren]

Hi @ViktorNova, thanks again for the feature suggestion.

I'd like to discuss what you actually require from Fabla 2.0. If possible, we could discuss it all on one issue? I'll rename this one to [feature-requests] Fabla 2.0 Wishlist. Bullet points would be awesome, with a little description.

Feel free to dream big, but please remember I'm only one person trying to make this actually happen! Cheers, -Harry

[harryhaaren]

Currently this list stands as:

• Drag-and-Drop workflow support: see issue #35.
• Improved sample-loading / viewing: see issue #18.
• Filter per sample (lop, hip seperate, both with resonance is ideal)

[ViktorNova]

Great! Thank you for being open to suggestions, I will totally add any ideas I have to this thread as they come to me. I have a few more, actually:

• Adjust start time of sample Lots of drum samples have a small gap of silence at the beginning, it'd would be really handy to compensate for this without having to open the sample in an external editor (no need to adjust the end time since we have the envelope)

• Rename pad Sample names are often pretty crazy/long, and don't always have the most meaningful filenames, especially in first part of the filename that fits inside Fabla's pads. For instance, I have an instance of Fabla that holds all my kicks for live use, and nearly every pad says "KICK!-Dance--" or something similar, with my meangful filename cut off, so I have to click the sample to see the full name in the waveform window.

  I think the pad name should display in or around the waveform window in addition to the filename, maybe in orange or blue with a larger font so it stands out? The pad could be renamed by right clicking the waveform, and the default pad name would just be the filename

• Dynamic resizing of the GUI It would be extremely cool if the GUI elements could resize to fit the window size, kinda like Non-Sequencer does. Like have it start the same size it is now, but if the user resized/full-screened the window, they'd get a giant (or smaller) set of drum pads. Would be sweet on tiling window managers too (Fabla among many other LV2s are a little awkward on tiling window managers at the moment)

That's it for now, I'll keep em coming! =D

[harryhaaren]

Ok, so I've updated the Wiki page where I can keep track of the actual features that are happening, wishlist features, etc: https://github.com/harryhaaren/openAV-Fabla/wiki

Thanks for these, they've made the cut; with the exception of entire UI resizing, which might be tricky, but its noted there.

[ViktorNova]

Awesome! That is exciting. No problem, I'm not much of a coder but interfaces is totally my thing, so I'm glad I can help in some way =D

[spectromas]

• If the sky is the limit then an output port for each pad (so they can be routed to their own track/channel).
• integrated fx for each pad (artyfx built n maybe?)
• sample preview when loading (be able to listen in the browser rather than having to load it up first)

That's all I can think of at the moment.

[harryhaaren]

Hey @spectromas, thanks for joining in!

• Output port per pad: the issue here is that hosts don't currently support multi-channel routings and such. So this "feature" would actually alienate Fabla from a range of hosts that only handle mono / stereo LV2s. So its not gonna happen, sorry. (In future, if an extension etc was widely implemented by hosts, I will most certainly entratain the idea.)
• Integrated FX: please list what it is you'd like to have! The following are already there:
  • 2x Filter (switchable hip / lop / band, with Resonance control)
  • Suggestions here!
• Sample previewing is listed: https://github.com/harryhaaren/openAV-Fabla/wiki

[grejppi]

I suggested this last May on #lmms but never remembered to open an issue for it... so here goes

23:21 < grejppi> lmms can't save folders inside an mmp for obvious reasons, so
                 it saves just the ttl
23:25 < HarryHaaren> ah yes, well.. fabla saves to wherever the host "tells it
                     to".. which means, whatever LILV does, which means... a
                     folder beside the .mmpz file?
23:26 < grejppi> HarryHaaren: yeah, if the host doesn't support state:makePath,
                 maybe fabla could save absolute file paths?
23:26 < grejppi> probably with the home dir replaced with ~
23:26 < HarryHaaren> ah yes, i guess why not. Generally not really a good
                     solution (for the obvious portability issues) but sure :)

[harryhaaren]

@grejppi, thanks. I'll make state:makePath a requiredFeature. I don't like the idea of having some portable and some un-portable presets.

[thorwil]

I'd like to see adjustable influence of velocity on filter frequency. The same for resonance is not quite as important.

Candidates for integrated FX:

• Resonator (using the sample as a 'driver')
• Saturation/Overdrive/Distortion
• Downsampler
• Bitcrusher
• Ring Modulation

[harryhaaren]

@thowil, cheers for the suggestions, a few questions as I don't fully understand what you mean with some of them.

• Velocity -> Filter freq: how do you input the mapping values? A low-note, high-note, and an "influence factor" with a range of +-2 octaves (in steps of 1 semi)?
• Resonator: I know of resonator filters.. is that what this is referring to?
• Satma (and Driva, but is currently not-yet-released) from ArtyFX will take care of Sat/Over/Dist
• Downsample, sure.
• Bitta (ArtyFX)
• Ring Mod: what waveform inputs (just sine)? How to set the frequency?

Cheers, -Harry

[son0p]

May be out of scope, but a feature for Beat Maker producers could be auto break a loop into rhythmic components, like ReCycle, and spread individual samples in pads.

I am no aware if there is a more handy tool for this, but FreeCycle seems too old (2005, I can't even compile for a QT3 -QT4 conflict) http://freecycle.redsteamrecords.com/build/

and Snd can be a long deep road. https://ccrma.stanford.edu/software/snd/snd/snd.html

[thorwil]

Re Velocity: I think some synths get away with a single Velocity->Filter-Freq value, sometimes labeled with %. No idea how common it is to have the played note influence the filter frequency. For a drum sampler, I guess you don't have to bother. If I just can use a single sample and get a more and more muffled sound when lowering velocity, the job is done.

Now if you wanted to offer more control, you could have a switch for static vs velocity-dependent filter-freq. If the later is active, have 2 values for what zero and maximum velocity will mean and as icing on the cake, a parameter that changes the mapping from exponential over linear to exponential in the other orientation. An editable curve (like the curves for gradation in GIMP or Photoshop) would be rather excessive.

Resonator: Anything that deserves the name would be cool. Be it based on impulse response, fedback filters or any physical model. But I mainly thought of the technique of the Korg WSA1, using PCM samples as drivers, fed into physical models of simple tubes/plates/strings. Probably 2 numbers too big to be just another feature :)

Ring Mod: sine, saw, square/pulse, noise, perhaps? Fixed frequency, velocity influence, LFO, random. An option that makes the freq rise or drop on quick successions of hits? .... though that could become a paramter jungle, quickly.

[harryhaaren]

@son0p, thanks for the beat-slicer suggestion: its actually already in the features list on the Wiki page: https://github.com/harryhaaren/openAV-Fabla/wiki

• Loads "drum-loop" samples, with auto-slicing

OpenAV wrote a plugin years ago (before OpenAV even released code publicly!) that was a "breakbeat-reconfigurator". The code is very bad, and unmaintanable, so will not be released. See (the "old-style") screenshot here:

I agree that such a workflow needs to be catered for, and its something I'm looking forward to creating! I had a lot of fun with Refractor, even in its basic state... so lets see! Cheers, -Harry

[harryhaaren]

@thorwil, cheers for the details:

• A single dial for velocity -> filter freq, with +2 to -2 octaves of fundamental freq.
• I'll look into some resonator filters, and see what I can cook up.
• Ring Mod is parameter jungle etc, so I'll delay this until 2.1.

[spectromas]

As far as the beat slicing there is always https://github.com/rock-hopper/shuriken I don't know if it would be far too much work to implement somehow though?

Reverb would be very useful to add to the list if fx (or are all ArtyFX going to be in there?).

[harryhaaren]

@spectromas

• another person requested per-sample outs, so more discussion on per-pad outputs here, including a detailed description (with diagrams) of routing workflows: https://github.com/harryhaaren/openAV-Fabla/issues/37
• beat-slicing, that repo doesn't build here now, i'll check it out properly (and try fix it) another time. Using Aubio's onset() detection is really simple, and definatly something that can be included (updated on Wiki).
• All ArtyFX? Some don't make sense, and others I think I can improve on instead of adding thier current versions... but yes, ArtyFX is essentially my DSP toolbox :D

Cheers, -Harry

[spectromas]

@harryhaaren thank you for the link, very in depth and interesting. Now you mention it I do remember you mentioning the problems with per-sample outs, it makes sense.

You're right, not all of them would be suitable. Delay and reverb, along with the others mentioned, would be essential in my opinion.

[harryhaaren]

Added Delay-send to master Fx, thanks.

[ViktorNova]

(I originally posted this somewhere else but moved it here as it seems more fitting in this thread)

• FX send busses

Say 4 extra outputs per Fabla instance that work just like FX sends on a mixer board, where each pad has it's own knob for Fx send 1-4 that adjusts how much of each channel gets mixed into each output. If this was combined with a pre/post fader button, it could even be used for external effects that needed 100% wet signal without the complication of per-pad output.

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 external effects, and wouldn't overcomplicate Fabla for people who don't use the feature

[harryhaaren]

Hi @ViktorNova, I think you are referring to this post that you made earlier.

I would like to note that extensive discussion about having more than a stereo audio outputs has been discussed (both on the thread and on IRC (see summary here).

To sum up the above: The problem in providing "per-sound-sample-outputs" is that the host can no longer automatically route the outputs, causing every user to have to manually route the outputs of the plugin. Particularly for new users routing is confusing, and workflow is not an area where OpenAV will allow compromises.

1. Adding more outputs to a plugin causes the user to have to think about routing. It is currently not possible to automatically and transparently handle the FX send busses feature.
2. I do agree that the feature would be nice, and the way to pragmatic solution this is to firstly implement these FX busses internally inside a plugin.
3. At a later date, when the appropriate LV2 extension is completed, hosts will be able to work with the plugin to provide FX send busses transparently to users. (See Robin's comment from IRC "the host should be improved to honor LV2 audio-port groups and properties").

[ViktorNova]

@harryhaaren This makes total sense, I was wondering what the current state of this was in LV2 and your discussion on the thread you linked sums it up in perfect detail. Thank you for going into this, it is exciting to know that these things are making some serious progress and to see the LV2 format evolving. I am very much looking forward to Fabla 2's internal effects!

[harryhaaren]

@ViktorNova, Indeed these are exciting times! I'll be posting a status-update on Fabla 2.0's design soon, so more info on the way!

[ssj71]

@harryhaaren and @ViktorNova If NTK is going to be used, then currently there is no way to do UI resizing in LV2. This is because the LV2 resize extension gets called but the instance of the UI created in your instantiate function is out of scope. I have faced this with the infamous plugins. If the extension gets fixed then it will be relatively simple using cairo_scale. Unless I'm missing some workaround (in which case please fill me in).

[harryhaaren]

@ssj71 resizing is no issue? just resize the NTK "window" that is your top-level widget, and the rest will scale. Its not out of scope, its now in your LV2_Handle*? Or at least... can be if you store it?

Side note, Fabla 2.0 will be built using AVTK (also 2.0), and will not depend on NTK. I'm currently looking into widget scaling for this new AVTK.

[ssj71]

Well, if you are moving away from NTK then there's not really an issue. The problem is because NTK Doesn't get resize events from the X window that it gets embedded in. Perhaps if in the idle function you can get the size of the parent window and call resize, but I thought I tried something like that. When the resize extension is called you are not passed the LV2_UI_Handle. That is exactly the problem. Anyhow, I don't know if this is the place to discuss it. Thanks though.

[harryhaaren]

Hmm ok perhaps I'm misunderstanding and there is some issue there. I suggest #lv2 on irc.freenode.net or else LV2-developers mailing list. Cheers, -Harry

[ssj71]

http://lists.lv2plug.in/htdig.cgi/devel-lv2plug.in/2014-August/001413.html feel free to pipe in on an old thread.

[prokoudine]

The only reason I don't use Fabla is because it doesn't provide a way to use multiple samples for different velocity ranges. I get it that you are all electronic music producers and probably couldn't care less. Still, if you want feature requests, this one is from me :)

[harryhaaren]

@prokoudine, accepted, now on feature list.

[harryhaaren]

Coding started today, with significant progress made already: http://openavproductions.com/fabla-2-0-code-and-design-underway

[naught101]

Pitch shifting. Base shifting + Velocity -> Pitch knobs.

Ideally, both time-dependant shifting (sample stretching), and time-independent shifting (resampling), and time-stretching (resampling, maintaining pitch).

[harryhaaren]

@naught101, thanks for the suggestions.

• Resampling type variable speed playback will be built in to 2.0
• Time-stretching will (most-likely) be added in 2.1, as a process-in-place operation. That implies that it is not a dynamic control, so it is not possible to map velocity to it. The reason for this is that time-stretching is a quite CPU heavy process (if done to an acceptable level of quality), and since this time-stretching would be per-voice it would cause too much CPU usage.

Thanks, I've updated the feature list on the wiki. Cheers, -Harry

[kroll-j]

• adjustable sample start - mappable to separate MIDI CCs per pad
• adjustable loop start & end - both mappable to separate MIDI CCs per pad
• different loop modes like forward, backwards, ping-pong, configurable per pad
• cross-over transitions to make loops less harsh, with configurable transition time (0.0 to 0.1 seconds or so)

This would make it really interesting for me for live use.

Thanks for the cool stuff you make!

[harryhaaren]

@jkroll20, thanks for the suggestions, see points:

• Adjustable start: what about layered samples? Do they all have the same start offset? (seems unlikely...) so what would you like to have happen in that case?
• I'm interested in the Loop stuff you're talking about. Note that there is currently no loop modes for sample playback per pad, so this is an addition that I'll be putting into 2.1... if at all. Are you use Fabla is the place to have loop-playback?
• Would it be a better idea to create a different tool that just does loop playback? I'm brainstorming for ideas that musicians actually want for live use, so there's a lot of interest from OpenAV's side, I just need to think where is the right place to implement it!

[nicopan]

Hi Harry, I suggest:

• pad: adjustable midi note
• pad: adjustable velocity curve
• main: ALSA midi in

Thanks Nicola

[harryhaaren]

Hi @nicopan, thanks for the suggestions.

• What is the use-case for adjustable MIDI notes? currently its mapped midi note 36 = bank A pad 1, and pads auto-count upwards (with bank B following directly after bank A etc etc). I'm not against doing this: i just don't see a reason just yet? I'd like to hear your reason! Its quite possible to do in the code, but I'd prefer not clutter things unless it improves workflow!
• Velocity curve: what does this value map to? Do you mean MIDI-velocity -> Fader (with adjustable curve) or Midi-velocity -> note-volume? Or perhaps both?
• ALSA MIDI in doesn't apply to Fabla, as Fabla is an LV2 plugin. The host that runs the plugin determines where the input comes from (JACK or ALSA MIDI), not the plugin. The a2jmidid project allows moving of MIDI data between JACK + ALSA, so this shouldn't be a problem.

[ViktorNova]

Adjustable MIDI note would be very cool, it would allow Fabla 2 to be able to much more easily dropped into an existing setup, or for someone to migrate their MIDI sequences/drum brain/etc from another DAW or OS

This brings up an interesting realization about rearranging pads though, as mentioned previously - we are looking at the 16 pad grid no longer corresponding to midi notes 1 through 16 on the different octaves as it does now.. which would be totally fine as long as the midi note is clearly displayed on the pad..just thinking out loud

What are your plans so far for how Fabla 2 will handle the 4 banks, I mean as far as midi note assignment?

[harryhaaren]

• Adjustable MIDI notes to aid transitioning: Good point, thanks. I'll push this till 2.1, as I'm drawing up a list of finished-things before feature-freeze to 2.0 release. There's a lot left, but there's serious progress too!
• Current MIDI note mapping:
  • Bank A 36 - 51
  • Bank B 52 - 67
  • Bank C 68 - 83
  • Bank D 84 - 99
• Optional MIDI channel mapping mode: (exists in code, exposed in UI) Is this useful for musicians? I don't want to over-complicate this!
  • Bank A 36 - 51, MIDI Channel 1
  • Bank B 36 - 51, MIDI Channel 2
  • Bank C 36 - 51, MIDI Channel 3
  • Bank D 36 - 51, MIDI Channel 4

Again, feedback appreciated! -Harry

[nicopan]

Hi @Harry,

• @ViktorNova explained better than me what I intended ;-)
• For velocity curve I intend how MIDI-velocity affects the amplitude of the pad's output. It would be good to have the control of that curve, from a straight one to a logaritmic, or even inverse. I take as a reference the Velocity option of NI Battery 3 (http://nicolapandini.damai.it/tmp/velocity.png). To explain more, I attach an image showing the differences in velocity curve from standard LinuxSampler (Amplitude(dB) = 20 log (127^2 / Velocity^2)) and NI Battery: http://nicolapandini.damai.it/tmp/gain_curve.png
• Alsa midi out: I haven't noticed that run.sh uses jalv... sorry :-)

[harryhaaren]

@nicopan , wow thanks for the details on the velocity curves: awesome. I'll keep it in mind, but I will push it to 2.1 too, I really want to get a stable 2.0 out with minimal features soon. I've updated the Wiki page, see the Wishlist / 2.1 section. Thanks again!

[ViktorNova]

@harryhaaren I agree that the banks and MIDI channels shouldn't be over-complicated by default. Maybe a good compromise would be to keep the default MIDI mappings as you have them with all the banks on one channel, but to then have the option available to assign a specific MIDI channel to each bank for the advanced users who need it? Combined with assignable notes per-pad, this should probably make everyone happy =)

I came up with a few more ideas:

• "Reset to default" option for setting the per-pad MIDI note Perhaps an option to reset the whole bank back to default MIDI assignment too, in case someone gets too carried away assigning notes to pads and wants to go back to normal. This should definitely ask for confirmation!
• MIDI learn for assigning notes to pads

• Expandable/collapsible section(s) of the UI This is more of an idea I'm throwing out than a feature request, but in case the UI in 2.1+ starts to get cluttered with all the awesome stuff you are putting in there, it might be cool to have certain sections that are collapsed by default to present a cleaner interface, or that can be collapsed if desired

  For example, Poise does this by collapsing the sample browser on the left sidebar by default.. also it could maybe be a good place to put some other more advanced options like setting up multi-samples, renaming pad, assigning MIDI channel, etc., stuff that doesn't need to be visible all the time, or stuff you don't want to accidentally hit when tapping out a beat live on a touchscreen, for instance.

  I imagine you have probably worked most of these things out already, so it is just a idea

It's very cool to see how much progress you are making! =) I am excited for Fabla 2

[harryhaaren]

@ViktorNova, thanks for the detailed feedback:

• I'll implement the MIDI thing as you suggest. The danger here is that we build lots of plugin-host DAW-type features inside Fabla, and users are presented with them twice: that would cause headaches even for advanced users! Assignable MIDI however is something I think could be valuable, so I'll push it to 2.1 and implement it then.
• Expandable UI sections: Yep, that's currently already working! The "Sample browser" functionality replaces the pads temporarily, and allows easily auditioning samples from disk. Then when a sample is loaded to a specific pad, the Pads-view returns. Screenshots to follow (the sample-browser dialog needs some attention before I want to publicly show it.. )

Thanks for the input, and keep an eye on progress on the wiki, Pad Features is only missing Renaming, and there's only a few DSP / UI items left too. Note that I have pushed quite some features (Master-FX, more voice-FX, AuxBus etc) to 2.1: I'd love some useability feedback on the sample loading and current layout before continuing to implement the other features, hence the 2.0 release with a reduced feature-set.

[harryhaaren]

@ViktorNova , update: I've implemented file-name scanning in a folder, and if all samples in a dir have a common prefix, it isn't shown in the UI: this should solve your Kick-DANCE-xxxxx.wav issue from before.

This screenshot is from the AVTK demo app, but it will be similar (but polished looking) in Fabla.

[naught101]

Just to be annoying with the output-per-pad thing: What would be really nice would be to have a way to use just the kick (or an arbitrary pad or set of pads) as a side-chain input to a bass drone. At the moment, in Ardour3, there's no nice way to do this, except either having a separate instance of Fabla on a different track, or programming the kick manually with samples.

I'm not asking for this in Fabla 2.0 or 2.1, but just some things to think about:

The extra-output-per-bank thing doesn't really work here (when you want to use the kick but not the snare as a side-chain controller), unless you want to break the midi drum mapping standard, which I think it would be preferable not to do (makes using controllers annoying, for instance).

Could the extra outputs just be assignable, instead of per-bank? Like, all pads are directed to standard Stereo out, and all have toggles or volume knobs to send them (post pad FX) to the extra outs? I wouldn't care how many extra outputs there were, but at least a couple..

[harryhaaren]

@naught101, I love this topic ;-) The last point: that is exactly the solution I'm proposing: (see 2nd diagam here but with 4 busses not 2 )

• 4 auxilary output busses
• every pad (regardless of bank) can route to any aux bus
• including a dial to control the send amount.

Note that the icing on the cake is that MIDI CC values can automate these send dials, which means that we have per note control of reverb / compression / etc if we want. That's unheard of in Linux audio until Fabla2! (The host will need to be able to automate MIDI CC in order to utilize this feature: Ardour can already do this, see screenshot below!)

This is planned and will be implemented as such for 2.1. I agree that the current workflow with Fabla1 as you have described is sub-optimal, and that's actually the reason Fabla2 was designed like this, and with the AuxBus feature.

Cheers, -Harry

[naught101]

Sounds good.

Another idea for a future release: allow LV2 instruments instead of samplers. This'd be useful for 808 kicks and things like that.

[harryhaaren]

@naught101, If you're suggesting synth functionality as the source of material in each pad, then you're right on the money. The code is designed to have multiple sources: there can be a sampler and a synth active on a pad at the same time. I like that you're thinking forward to this workflow: i think its something that could be very cool!

For now, Shhhhh, don't tell anybody. This synth functionality will take a while, lets not spoil the surprise when it hits ;)

Current plan:

• 2.0 release ASAP: some bugfixing / UI work / master-FX remain.
• 2.1 Includes AuxBus, FX sends, and an "overview" dialog for mixing.
• 2.2 Synth functionality, and various other improvements...

Cheers, -Harry

[ViktorNova]

@harryhaaren That is neat about the file name simplification. I hope it can be disabled if needed (to show the whole filename) just in case? It's all looking and sounding very cool, I can't wait for 2.0!

[harryhaaren]

• Disabling "Short" names; of course yes.
• OpenAV is in contact with some sample-creation folks, and there's a very beautiful jazz funk kit coming out with Fabla2, multi-layered samples, and just gorgous. And its free/libre too!