@here Given the interest in this request, I have moved it to #drafts . You got a template for the description (that anyone can edit), and you can also vote this request.
@here what should we do? Push for this request or archive it and focus on āOutput to new chainā module in the Grid instead?
There are four people who have expressed support herenf that is four potential votes.
Arenāt you talking about the same thing?
Yes we are - I think Andrei was just remarking that, while there would be a workaround if his proposal were implemented, it would still be cool/practical.
I have copy-edited the description. There are still some details that we could sort out. Please check.
The use cases are not explicit in the description right now, and perhaps it would be useful to mention the main ones. Some VSTs are instruments, and this feature would bring the sounds of these instruments to The Grid, right? Other VSTs provide audio effects or MIDI data, and I guess people interested in this feature also would like to to use those? What is your main motivation here, the instruments or the effects?
I guess it would be useful to link to Note Out module for The Grid, and perhaps even Containers within the Grid ? I may be completely wrong, but maybe the development of container modules for The Grid would help solving some challenges brought as well by the development of a module to ācontainā a VST plugin.
I donāt understand what this means. About āpotentially bitwig devices tooā, this is out of scope for this request. And I donāt see why this feature would make patches visually more readable.
I canāt speak for others, but this is how I use the VST host modules in VCV Rack and Voltage Modular:
I do use them for both effects and instruments. It would probably make sense to have separate modules for those two (the way VCV Rack handles it), not jus tone, as one has audio ins and outs as main features, while the other only has audio outs but would like control signals for all of its parameters. Plus thereās hybrids, but I think already if the two biggest categories (pure instruments and effects) were handled, that would already improve the gridās possible applications by a lot.
Possible use cases / things I did recently in systems that have these:
- Use a VST as a sound source that can then be mangled with other things - for example, a 3rd party synth patch that is triggered and controlled by the grid then go through processing in the grid again
- Use a 3rd party effect towards the end of the chain, like a reverb, or even something crazy like a glitch processor
- Use a 3rd party effect within a voice or a small part of the chain, for example, a distortion, or some easy multi band editing of a particular sound before it gets passed on
- Have interactions between different 3rd party effects that usually donāt interact (use one to modulate the other in unexpected ways)
Thereās lots more possibilities, but those alone would make things much more flexible.
@haslo Thank you for this explanation, @LXIF, what do you think? We donāt need to get into a lot of details in the description of the request, but Hasloās comment above clarifies some points a lot (at least to a non-expert like me).
This is currently the third most voted draft. Letās complete it and move it to #features !
(Also, if someone could volunteer an image i.e. a screenshot of VCV Rack hosting a VST, the request would look nicer and more visible when featured in our new image highlights in the main page.)
What do you think of this one? Too busy?
Also, I just realised, that would mean we could then host VCV in Grid
Hereās another one, as Shimmer is paid / Supermassive is free:
ā¦and another, where I used Host for sound sources:
@haslo Thank you! I think the Supermassive screenshot is visually more colorful, and also that UI is probably more familiar to more people. Now this request looks great in the main page.
Yes, these use cases make a lot of sense
Hereās my take.
-
If weāre to have this, why limit to VSTs specifically? It really should be device wrapper module instead (could be Chain device with whole chain in it as well) if we want features this direction.
-
Why do you guys think itās not a feature already? Most for exact same reason we donāt have even option for now to include devices in nested chains into polyphony stack (so those chains are internally duplicated for each voice, with parameter link to visible layer) - potentially this kind of setup quickly scales up to huge CPU spikes, way more impact than Voice stack can do. Still I am ready to vote for this option, it can be very useful if you know what youāre doing. Same for device wrapper in Grid.
Initially I also wondered why VSTs only. What if I want to have i.e. Phase-4 inside the Grid, wouldnāt that be cool? Then I thought that the interest by the people voting this request is clearly to bring in VSTs to The Grid. And if that would be implemented, I bet Bitwigās instruments would get in as part of the deal. Technically they might be simpler to resolve than the VSTs anyway.
About CPU spikes, maybe, but if other products manage to do thisā¦ Anyway, this is a problem for the Bitwig team to consider if they are interested in this feature. I donāt think it should prevent the publication of this request.
yes, as Iāve said we should still do this feature request, even if itās potentially something Bitwig devs would be strictly against. we just donāt know.
This is an important point. Should this request be asking for two modules instead of one? Or do we leave it just as a suggestion in the description?
I think leaving it as a suggestion is fine. Audio inputs that the hosted plugin doesnāt use (because itās a generator) arenāt an issue, as long as the system can handle it. Whether one or two plugins make more sense from an implementation perspective is something the devs themselves know best.
Alright, thank you again for all the input. I have edited the description trying to bring interesting elements of the discussion. Please review. If there arenāt any blockers, I will promote this request to #features in a couple of days.
honestly Iām still not a fan of āVST moduleā instead of device module, which is more universal and is the goal here anyway. I understand that for people coming from FL, thatās what they want to call it, but Bitwigās own devices are not VSTs and there shouldnāt be any reason to make such module exclusive for VST plugins only.
I suppose for title we can have VST/device module for better clarity.
also I just noticed something when reading this:
so if we get devices in Grid, that implies we need a separate āMIDIā type wire? or else itāll need at least all the inputs that Note out module needs from a different feature request, therefore it will rely on that to be implemented first?
one other thing to clarify, getting devices in Grid itself instead of nested chains means having them stacked per voice, so there are some implications with that. although personally I wouldnāt mind āexpertā features that can easily tank CPU, it seems to be Bitwig developers actively avoid situations like this. when average user sees poor performance without understanding why and seemingly doing simple actions.
there could be a āmake noteā node but a midi note is really nothing other than gate and pitch - a note-on message with a pitch and later on a note-off message. everything else (velocity, pitchbend, aftertouch) are all also just midi values. that being said, iirc VSTs are capable of much finer control than MIDI CCs for their parameters (which is why automation curves can give you a smooth filter sweep but a regular 7-bit midi knob canāt).
what iām trying to say is, you wouldnāt need midi cables, you could just give vst instruments gate and pitch inputs and and generic signal inputs for other modulatable parameters.
I know, Note out module is also seemingly no big deal to make, with same pitch+gate as basis + any other expressions needed, Iām just saying that itās same set of inputs and conversions (to midi) that needed for that feature request.
I have updated the description to mention devices first, but still mentioning VST plugins explicitly everywhere.
Iād leave this to the Bitwig team if they decide to implement this feature.
Is this good to be promoted to Features now?