Bitwig, NoteGrid, separate three voices

[@x-iso]

personally I prefer using Strum + notefx selector (in free voice mode) that allocates all notes to 16 channels, all in pre-fx chain, then you can address each note by channel from lowest note (and channel) to highest. that's assuming you know what to do with this. if you alrady expect specific notes to do specific things, then it's much easier to use Key On module.

[@joshuaschmalle_vlogs]

What do i need to do to get access to ur projects mate ❤❤❤

[@ollieark]

👍

[@McGyver008]

Well... this shows again, that Bitwig does not think on practical use at all ... This module can distinct 3 voices at best. But ... in order to use it for voice separation it simply is nonsense to limit the number of distintable voices to 3, unless this is not simply for primary school purposes... and such a stuff in an alleged "professional DAW" simply is ridiculous (like many things in Bitwig Studio meanwhile!)

[@mezzopotanic]

By the way, doesn’t Eurorack work differently? Didn’t they copy that, If you specifically can only work with discrete voltage levels, there might not be many other options if you want to be analog-like with Eurorack, but I’m not sure, For example, in Reason, which operates on a similar principle, they still haven’t managed to implement poly-CV cabling or interoperability between MIDI and their own gate and pitch CV. At least here, it works.

[@ucheattoh]

a software should have no such limitations except the developer is limited in the necessary knowledge to implement. these things are frustrating....not everyone can be a nerd and bitwig makes some things unnecessary hard....and nerdy

[@mezzopotanic]

@@ucheattoh But if you want to support hybrid workflows with physical rack systems, your hands are tied then it is not the developer issue

[@McGyver008]

​@@mezzopotanic Eurorack - according to my information - uses 'clocked' step sequencers, and the majority of them outputs one analog value (CV). But some additionally offer more signals at the output (partly even assignable to values given by "step knobs". Looks like EuroRack simply is more flexible... And in general my view of the comparison "Grid vs. EuroRack/VCVRack" is, that VCV e.g. simply is more CPU-heavy, but... is more flexible. Of course there are always limitations, but in case of a software solution of a modular system these limitations are somehow 'implemented'. Bitwig wanted ro have a maximum of voices throuput (as visible in the strenghtened Voice Stack model, but this somes with limitations, because as long as the DAW isn't run as a compilated (_ n a t i v e _) machine code, like a c++ or c compilation, it needs significantly more CPU cycles for processing, so that for real time routines one need to make heavy use of SIMD-solutions (vector operations) on the CPU. As a consequence one need much bigger data chunks to be processed in a sequence, forcing much higher latency in case of feedback loops (where the feed back data can interfere with the incoming data instantly).). This is different in VCV Rack, which is capable of such feed back, but... with much less parallel voices... (because I suspect it also not being comiled). And to thos Java-"soldiers" here: Simply have a closer look at performance tables of different code snippets, which are realized as interpreter code, "byte code"/"token" interpreter (like Java, Python, etc.), C, Object C, C++ or even Assembler/'pure' machine code in their individually strongest optimization. You will find not even one single precedure, where interpreted code is halfway comparable in it's performance with compiled code. And to those, who argue with the 'complexity' of comilation of big projects: Yes, it indeed IS complex, BUT if there is a sustainable development, where at least 2 codelines exist in parallel (what doe NOT mean, both are developed independently, but instead ONLY operational code of "experimantals" which did not produce errors (for this purpose of course a _ v e r y _ h e a l t h y _ user-developer-communication is essential - what NEVER worked for Bitwig at least during the last 8 years according to my own experience!) are placed into the 'stable' code basis - which then most likely is able to be compiled with less enough problems. And everything eles stays "interpreted" - period. But Bitwig seems to be not only a small, but also a completely learning-resistent company, as they never really considered to re-orient their business policy and model (as well as their target group...) and ... still insist in their goal to publish _c l e a r l y _ n o n - p r o f e s s i o n a l - software to mostly non-professional, hobbyist "musicians".. That's why I seriously consider to leave Bitwig in a foreseeable future to move towards a really professioal solution. Bitwig - sorry to say this - is a typical representative of our current short-sighted and high-paced lifestyle, which - although looking awesome (at first sight) - is a whole bunch of weaknesses, of pit falls and provisional 'solutions', which at some point in the future will fall them onto their feet (if nothing changes over time). I wouldn't even consider their unsustainable software development as the biggest problem, but much more their completly missing willingness to learn from mistakes.

[@McGyver008]

@@mezzopotanic Your interface might be limited, but this can not be applied to the whole software solution - which can use internally it's own models. But again: This needs highly professional and sustainable software development - which is ecerything but desired by Bitwig.