Ditch different hard coded Rack types in favour of Rack categories
I find it very limiting that it is not possible to add or remove inputs or outputs from the pre-defined rack types (instrument, processor, MIDI). You find a gem on Patchstorage, just want to add a CV input, and at first you have to do annoying copying of sometimes a long row of modules.
My suggestion is to ditch these hard coded rack types, and only use the generic “Rack” module instead. To keep compatibility, an additional option “Category” could be added to the Rack module that will load/save a rack in a newly created or existing preset category. Loading an instrument rack for example would load a Rack with the instrument configuration, but would always allow it to be modified or saved in another category.
And having the option to use custom categories would make it much much easier to distinguish between Factory presets and your own creations - and back these up.
Comments
Preset categorisation is up to you to arrange however you like.
Different rack types are there for a reason - generators, processors and midi racks are completely different animals and there is no obvious way to simply convert one into the other.
Generic rack will allow you to customise i/o of a rack, so that’s already a possibility. You may want to lobby patch creators to share their work in that format to keep it open for further customisation.
Once you go Rack, you don't go back.
Not for me, to be honest. It really depends.
"would make it much much easier to distinguish between Factory presets and your own creations - and back these up."
huh? you create your own folder structures , what doesn't work here already?
my ish is here, factory presets are in the subfolder ...
Depending upon what I'n designing the Instrument/Processor/Midi racks keep me focused on what their supposed to do.
When I'm freestyling a design I almost always use the generic Rack.
if you want to save your own creations that go beyond midi, instrument, processor
you can just save whatever as track-preset ...
no need to pack it in a meta rack
I save Track presets for the really complex stuff which normally does include a meta Rack.
I have no strict one way of creating otherwise what am I creating in the end.
in 99% of the things I do im totally fine with midi, instrument, processor - just put them one after the other if needed ... 😀
as it helps me to not lose the plot of what is going on 😂
if I have odd stuff like every 4th audio transient triggers some other event, they go in an "odd ball" folder ...
Whatever works for you. :)
I generally start simply and then inevitably it becomes really complex that's why I like the flexibility of the Rack.
dRambo as whole suits my mindset as you well know because we can do what we like without blowing anything up.
racks inside racks sometimes create odd looking things (...) , so I try to avoid that
it doesn't work with the "building block preset racks" I created all the time
(im just to lazy for long elaborated copy & paste orgies out of this rack into that rack I guess ...)
@gravitas
That much I do know. ;)
I've been focusing on simplifying as much as possible in regards
to the design interfaces these days so that when other drambonauts
play with the presets I make they can be as simple or as complex as they like.
Part of the reason why I haven't released the d1-dRambo Euclidean sequencer yet however that's for another thread.
hm, interface ...
if stuff gets really complex I just pipe out some morph modules infront of everything with "here are the macros you want to adjust" and more or less hide the rest (usually there is "dont touch that stuff" that will ruin things if you dont know what's going on)
this works on everything, and it doesn't matter anymore if its a bunch of racks, or a long snake of modules or layers or a meta rack or what have you
As mentioned earlier.
Whatever works for you. ;)
yes, thats why we dont understand this thread
everything is possible, simply do as you please 🤷🏻♂️ :)
The problem with the current preset folder layout is that you either have to back up everything (including the factory presets), or you have to go and pick your own presets from every type of module. An independent folder structure for user presets - and that is ideally iCloud compatible - would be best. I suggested the custom categories so that at least for the different racks I would be able to create categories like "my_instruments" etc. that could be easily found, backed up and copied in one go.
And I still don't see any compatibility issues in the case the generic rack template would be used for everything. Modifying a MIDI rack for example and adding a CV input would not crash Drambo.
@catherder What keeps you from only using the Rack module from now on and create preset sub folders to make your own categories?
That's basically what I do with presets for modules that warrant categories, like Sampler instruments.
Also, you're free to rename and move files that come with factory content.
@rs2000 thanks for the suggestions. I will have a play with Drambos preset folder and see if I can sort things differently. With regards to the Rack module I am doing this already for my own creations. The change I am suggesting in this thread is more about modifying 3rd party modules (Patchstorage) without the need to copy and paste from one of the pre-defined rack templates into the generic one.
Seems all I came here to say has already been said, better.
But I love the custom rack since the beginning and vouched for it here several times. I like it for the modularity, and portability/reuseablility. It takes extra connecting effort, though.
I also prefer to build freely, but when I find something useful in mine or other people's creations, there's nothing stopping me from copying the portion I want inside a rack, connect i/o appropriately, and save the rack for future use.
@catherder Got it. I agree that it would be more convenient but putting on developer's glasses for a second, you'd be surprised how much effort (=time) is required to make such auto-remapping a robust process, and still it will not be possible for all rack types.
Plus if it's introduced for racks then it will naturally make sense to cover other modules too, because quite a number of modules have received updates in the meantime and the mechanism for now is to keep all historical modules ready for use under the hood. You cannot add older versions of modules in a new project but you can always load a project that makes use of them.
What @pedro suggested looks like the way to go in these cases.
also, rack in rack works fine afaik.
so, opening any 3rd party racks inside a generic rack, building on top and saving in your own format/structure should make the process more seamless.
This
@rs2000
putting on developer's glasses for a second
Ha... I would be glad to be able to take them off for a second
Plus if it's introduced for racks then it will naturally make sense to cover other modules too
That's what we call the "Já agora's" which is portuguese for when some improvement is being implemented and the client says "while we're at it, why don't we do...". Classic client.
@rec @supadom
Racks in racks work fine for me too
I wonder if modulating inside racks directly (bypassing rack's inputs, as opposed to expose the modulation source and keeping the rack a "black box") has any impact on performance/memory
I wonder further if there's any chance this might be what triggers that very elusive bug(?) when all modulations stop working and you have to restart. It's not a crash, it works fine from autosave. I mean if you have a ton of modulations to racks inside racks, it might run out of modulation-RAM or whatever? Only mentioning cause I'm guilty of that
@pedro
I wonder if modulating inside racks directly (bypassing rack's inputs, as opposed to expose the modulation source and keeping the rack a "black box") has any impact on performance/memory
I remember @giku saying that everything running inside a rack happens inside its own scope in terms of audio processing, and my guess is that there could indeed be an issue that only pops up when a lot of inter-rack modulation is going on.
Like always, if you can reproduce it then please share it!
Thanks @pedro, is "já agora" something like "by the way" then?
no, they dont. ;)
dive deeper and you will see
I have examples somewhere where it gos horribly wrong, I can't remember what I named them, so I can't find them now
(simple stuff works like put an fx rack into an instrument rack)
lets see what I can put together in 5 sec
lets start simple an put an instrument rack and a processor rack one after the other into a generic rack
a synthesized clap and some reverb shenanigans
nothing gets auto connected - can't hear a thing
and thats only the start of it ...
bad idea ;)
the generic rack doesn't know what im doing and what I want to do - anything could be in here, how is it supposed to know how to connect what? ;)
maybe it doesn't need input connections and its triggering itself ect. 🤪
there are to many variables to make this work out of the box, me thinks, whatever solution you came up with it wont cover all cases. because anything & everything can be inside a generic rack
@lala
nothing gets auto connected - can't hear a thing
I don't get it, you want the custom rack to create (guess) the connections for you? The whole point of the custom rack is precisely to let you create whatever connections yourself. Of course once you've done that they will autoconnect as any other module.
See here I created an empty custom rack, added inputs for pitch/gate/vel and saved it as a preset (you can build your own presets, ofc, and create "rack templates" you can easily access via search).
Then when I include it in a new project it gets automatically connected, and I can go as many levels deep as I want. Haven't done a single connection here:
In my experience (and I used it a lot), it simply works, and I love it for my own designs.
Not saying it suits all user cases, though...
im on about "auto convert this structure into that structure" ...
and why it wont work
That’s impossible to implement, cause it would take for drambo to guess what you’re thinking, and AI isn’t there yet
thats what I am saying ^^