I think is complete fair , you should read the slides and take in consideration the time that skrylar invest to develop, maintain the plugin update with rack and jack, the bug fixed etc. and the jack transport , the jack session and midi is an important feature of jack , without it the jack connections with core audio is like alsa and pulse audio jack sink.
it is similar to jack, the price of Mainstage 3 is around 30 usd
I don’t argue about what’s fair or not, but I’ve read those slides and I haven’t found those analysis and strategies proposals particularly convincing, even if I empathize with the author. Investing time on an open source project, not ready to be trusted for live use, led by a single other person, is known to be risky. A safe positive outcome can’t be assumed.
I appreciate enourmously open source developers’ work. I’d buy you all people a drink. A big problem is that I don’t do online micropayments or support crowdfunded projects. Maybe most other people do; maybe not…
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.
Managed to get the 1.x dev branch to build (with some difficulty )
what did you decide? How can we contribute to the development of SKjack?
that is really nice, but I m talking about all the jack features (specially the jack transport ), the community must make that possible
I absolutely rely on your JACK plugin, and would happily pay to support it.
Just wanted to get that out there.
Tested and built on the official SDK.
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.
+1 to keep the jack support (and perhaps improve it) in the Core
You shouldn’t, no. It wasn’t even supported outside of a patched build when I wrote this.
this topic is confused to me
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 ?