Forums
Fabla is the only DrumSampler plugin that allows me to encapsulate samples in presets.
The GUI gives this error in Qtractor. Carla opens the GUI correctly.
´´´
using block size: 512
FablaUI: Warning, host doesn't support resize extension.
Please ask the developers of the host to support this extension.
´´´
If it doesn't have a fix I'll use it without GUI. I just have to leave one instance preloaded in template, since if I load it from insert plugin it can crash Qtractor.
Presets can be made with a text editor.
I don't use it but maybe…
I don't use it but maybe check out http://openavproductions.com/fabla2/
Is your original issue…
Is your original issue represented here?
Thank you very much, I'll consider it solved then
I'm still trying to create a workflow that solves the project portability issue.
Having the samples portable from the presets helps, but it's not an absolute solution either, since you have to assign them again if you open them on another computer. They would even be preassigned, but I think the project should work completely if you open them on another computer, as long as the plugins are installed.
If it's a solution if they're not going to be distributed, since I would know perfectly well what's happening and how to solve it.
The drumlabood solution is to have its own samples folder in the user root. It works, but then you have to explain to the user that they should create it and copy the samples there. Same as before, yes it's a solution if I'm going to be the only user.
In the end I think there are two different processes, the creation process and the final artwork process.
I think the best thing is to work freely, without taking into account dependencies. Use the plugins and samples that inspire me the most.
If the project needs to be compacted for distribution, create a version of the samples in SFZ > SF2 > LV2 with scripts.
I don't have many thoughts…
I don't have many thoughts here other than to remind you the word "portability" means different things to different people. If you haven't already, it'd be worth taking a moment to define (to yourself) what your exact set of desired outcomes are. For example, maybe you're expecting Qtractor to be used by all parties who benefit from this degree of portability. If so, that's one thing. If not, that's a very different thing. When it comes to collaboration, understanding constraints and expectations sooner rather than later is going to be a big help.
I used to collaborate with a producer for years who was locked into the Logic thing (or something like it... I can't remember). That basically meant the only things I had to lean into were standard formats and protocols. We managed to find a few synths we could both run. i think they were Tal Noisemaker, and ODIN2. It was a ton of work on my end. I basically wrote my stuff, mixed down a demo (for reference) and would export the MIDI file which he'd then load. That started the "MIDI mapping" process which we got better and better at over time. Tracks that used one of the shared synths we both had installed were simple. For other tracks being driven from synths we could not both run, things got trickier as we'd have to shop around on his side of things for something that worked (sometimes much better!).
For audio samples (including stems I eventually started to mix down in order to avoid the problem mentioned above), I'd just add those to the USB stick along with notes I knew we'd benefit from.
I still remember the night I taught him about the .sf2 format which he was shocked by. We managed to figure out how to get his proprietary system to "see" a use the .sf2 bank I had brought with me.
It was a very tedious process that got better over time as we learned how each other work. I didn't know I'd explain any of that but suppose I did in order to reinforce what I was saying above. You have to know your audience.
Add new comment