The equivalent function as far as getting MIDI in over a single wire and two stereo outputs (with third party modules to get 16) is the baseline. It already existed on each platform.
What Linux (and mac, and Windows…) users receive through my plugin is a 1:1 (for whats implemented) mapping of anything JACK can do to a Rack module, which is a much tighter integration. This means port names and unlimited ports (up to what your computer can handle). I also had to write a special wrapper to connect with JACK, then debug that across three platforms (one of which I can’t use very well right now), so that you can have the module installed anywhere and if the computer you happen to run Rack on doesn’t have (or has a wrong version of) JACK, it doesn’t create mysterious errors or dependencies; it just doesn’t work until you do.
Core (and rm) do not support stacking multiple audio modules to get more channels. You need a special 16-channel extender module if you want more, and if your computer/desires are for more then you’re SOL. This plugin allows you to keep stacking extenders, name each port on the graph, and handles the book-keeping in the background.
In some cases the plugin even shows better performance characteristics (my laptop stutters with very few modules under ALSA+Pulseaudio, but can run an average size cabinet without any stuttering and without the multithreaded build. This might be buffering related, or Pulse related, but I’ve observed it.)
What would you suggest should be done, then? If you don’t think skilled work and an average bugfix time that is close to many enterprise SLA’s is even worth minimum wage, I’m not sure what to say.
Yeah, it sounds like a contradiction, but it’s also the plain truth in my case. I’ve tried to, but I can’t be bothered to deal with all the problems that come with Kickstarter; and I haven’t used PayPal or a credit card online for a while. Maybe I’m the only one; I hope all your other potential customers are better than me with regard to this. If they’re not, you may have an additional problem.
Oh, I do think it’d be worth! It’d be fair for you to get that sum. But I don’t think it’s realistic, given the niche audience of the product, the issues that may come with a crowdfunding-based strategy, and the additional troubles that may result from avoiding the Plugin Manager.
I want to mention that I’m a Jack user. I’m replying in this thread because I’d like to see this product succeed. I can’t say I’m really enjoying the conversation here.
I didn’t mean to sound entitled in my last post and I certainly appreciate all the work that has gone in to it (it’s an incredible tool for jack users) but I thought at the time that Andrew was removing the jack option from Audio so to even get audio out of Rack we would be forced to use Alsa or pulseaudio, which is not great for many people, or pay for a plugin.
I’m certainly not against any kind of funding method you can come up with, it deserves everything and more that you listed in the slides.
To an extent, Rack didn’t exactly support JACK in the first place. It kind of did because RtAudio supports it, and people started distributing builds that had this patched in.
This is somewhat more clear
I don’t plan on avoiding the plugin manager.
If the plugins can be upgraded to the backward-compatibility headers in <2hrs then I may go ahead and do that. Gestures of good faith work both ways. This would also help ensure the goal is understood as not “hold everyone hostage” but instead “being sustainable.”
I’m also now thinking of writing up some questions to send to our existing plugin sellers (at least the ones doing tiered free releases [Hora?]) to see in very broad terms if they are satisfied with that model. A model where the code is always GPL (so you can build it yourself, a la Ardour, or Aseprites private compilation clauses), but the binaries are segregated in to “latest stuff added (pro)” and “delayed release (free)” on the PM might also work. This is a very common model used by creators with Patreon.
In your opinion, should I remove JACK support from Core and recommend users to download SkJack? Or should I keep it (and still recommend users to download SkJack)?
You should definitely keep it, many new users will be wanting to get going simply and Audio is fine for that. You shouldn’t need to use a 3rd party plugin to output to jack.
I never used a patched build (I always compiled by myself) and I have jack at least from the 0.5 without building jack, I like SKjack because it is titled as "First-class JACK support for VCV Rack " which mean all the jack features (midi, transport, clock, etc) I use Skjack but today the only difference that I can see is the capability to add mayor number of input and outputs.
I dont not know when you wrote the code , but when you announced the SKjack I already have jack connections in the core and RCM audio16. (without patched)
question: when I select Jack in the core module , is that jack or what ?
When I was building 0.6 from source, I turned Jack support on for RtAudio. When I selected it I remember it only partially working with two ports in the flow graph even though Audio had four. Maybe the version I built was broken and it worked in the officials
ahhh, I see
to make it work correctly you must open a jack I/O as dummie, for instance I open renoise with 8 imputs enabled and it is enough to connect the core audio.
yes, you are right now we can skip that step and connect the vcv rack directly.
but in other hand the ladish session can’t remember the connections (that is possible with the core audio) and we must reconnect it every time.
)
