You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm wondering about the current differences between what Carla can do vs. what mod-host/mod-desktop can do. Both in terms of LV2 support, and in future direction.
A lot more development has gone into the latter in the last few years, and looking at mod-audio/mod-desktop#58 at spears that there is a further "turning off the wheel", so to say, happening.
I might be wrong, but is mod-host the "core" of mod-desktop?
For a long time now the mod-host system has saved its graph (pedalboard) as an ingen: namespace powered save file, and can save a preset of its graph (snapshot). Am I using these items correctly?
Afaiu/iirc, 'subgraphs'(/rooms?) work better under mod- because there can be more than two channels for input and output(?)
Now mod- is becoming an LV2 plugin, is will become, arguably, the most LV2 host there is; essentially fulfilling, imho, the big "promises" of LV2 system; e.g. presets as bundles, and graphs as bundles (with graph-wide presets), alternative UIs, (though not networked separation of DSP/etc. and UI, unless I've missed something).
This aside from the web view (using the alternative UI principal) which has always been a prime feature, plus the newer moves to, one might say, "pivot" or "fill-out" the Store concept , with it's web-based user-save sharing and commercial aspects, to a streamlined form to make the entire system/ecosystem multiplatform, for open portabilities sake.
(And did I hallucinate seeing the suggestion of mod- specifically adding a channel system, thus overcoming the lack of bypass and MIDI addressing Carla Rack has?)
Can I please ask your comments about the distinctions and paths you see both projects taking?
Personally/selfishly, I would love to see the compact graph/dialog/rack and non-skeuomorphic Carla having the same level of LV2 host/plugin/graph/subgraph/preset/user-sharing functionality, but that's not going to happen in the next decade, prolly(?).
I'm trying, essentially, to better figure the cost-benefit of giving up on investing my time etc. in Carla when, with mod-, my plugin preset saves, graph saves, and graph preset saves will be portable between apps (theoretically to start with, re support ingen:). This being important to be because I highly believe that Data Portability is a most ethical principal/approach to software, e.g. all forms of save are truly sharable between app.
*I'm sure there are many practical caveats and hurdles to this, but it's a journey!
The text was updated successfully, but these errors were encountered:
This is a very good question that I want to answer, but there are deals behind the scenes that prevent me to disclose information in a proper way, and also makes it tricky to make plans for the MOD side.
Writing this here as a reminder to come back to this topic once things settle down, it has been very frustrating having to keep secrecy. Hopefully just a few more days now.
But as a super short info I can say Carla got sidetracked a lot because of Cardinal, I failed to realize how much time that would take to maintain, so very soon I am putting it in feature freeze mode. DPF will be similar too once I finalize 2 more features. Soon we have Qt5 being removed from ubuntu which forces me to do a bunch of work for "nothing", errrr
Plus I still need to actually find a home/place for myself, last few years have been a whole mess..
Lets go one step at a time, once the MOD stuff has a clear path I can write extensively about it.
I'm wondering about the current differences between what Carla can do vs. what mod-host/mod-desktop can do. Both in terms of LV2 support, and in future direction.
A lot more development has gone into the latter in the last few years, and looking at mod-audio/mod-desktop#58 at spears that there is a further "turning off the wheel", so to say, happening.
I might be wrong, but is mod-host the "core" of mod-desktop?
For a long time now the mod-host system has saved its graph (pedalboard) as an ingen: namespace powered save file, and can save a preset of its graph (snapshot). Am I using these items correctly?
Afaiu/iirc, 'subgraphs'(/rooms?) work better under mod- because there can be more than two channels for input and output(?)
Now mod- is becoming an LV2 plugin, is will become, arguably, the most LV2 host there is; essentially fulfilling, imho, the big "promises" of LV2 system; e.g. presets as bundles, and graphs as bundles (with graph-wide presets), alternative UIs, (though not networked separation of DSP/etc. and UI, unless I've missed something).
This aside from the web view (using the alternative UI principal) which has always been a prime feature, plus the newer moves to, one might say, "pivot" or "fill-out" the Store concept , with it's web-based user-save sharing and commercial aspects, to a streamlined form to make the entire system/ecosystem multiplatform, for open portabilities sake.
(And did I hallucinate seeing the suggestion of mod- specifically adding a channel system, thus overcoming the lack of bypass and MIDI addressing Carla Rack has?)
Can I please ask your comments about the distinctions and paths you see both projects taking?
Personally/selfishly, I would love to see the compact graph/dialog/rack and non-skeuomorphic Carla having the same level of LV2 host/plugin/graph/subgraph/preset/user-sharing functionality, but that's not going to happen in the next decade, prolly(?).
I'm trying, essentially, to better figure the cost-benefit of giving up on investing my time etc. in Carla when, with mod-, my plugin preset saves, graph saves, and graph preset saves will be portable between apps (theoretically to start with, re support ingen:). This being important to be because I highly believe that Data Portability is a most ethical principal/approach to software, e.g. all forms of save are truly sharable between app.
*I'm sure there are many practical caveats and hurdles to this, but it's a journey!
The text was updated successfully, but these errors were encountered: