Bitwig The Grid: It is just me...

[Taika-Kim]

Like I said, a "required depth" is either massive oversampling or one of the preprocessing methods. There is no magic formula that could remove aliasing from a trivial waveform. You will almost always have points that fall in between your available discrete samples. Anyway, what is your ideal function for a saw wave anyway? If you just draw a saw wave, it will have massive aliasing especially in the high notes. Read that paper I linked, you'll understand much better all this.

At least Disco DSP Discovery does calculation of the tables the first time it's run, or did 15 years ago. They apparently thought that the 8 megabyte lookup table (=wavetable) is too big to include with the download

Trust me, the audio science community wouldn't had spent decades on this question if it was easy. Of course if you don't mind the aliasing, things are easy. Like in the SID chip the saw wave is just a pure saw wave made with an incremental counter.

Btw I couldn't see anything about realtime calculation in the manual's oscillator section?

I'm not saying that some synths would not use realtime generation, I'm not a coder, just stating that at least until the mid 2000s when I studied some DSP stuff at the University, it was flatly stated that all VSTs use wavetables.

This is supposedly pretty cutting edge stuff from 2014, it uses lookup tables too: https://aaltodoc.aalto.fi/handle/123456789/12835

[gentleclockdivider]

I'm not saying that some synths would not use realtime generation, I'm not a coder, just stating that at least until the mid 2000s when I studied some DSP stuff at the University, it was flatly stated that all VSTs use wavetables.

Yeah right , we could already build osc's (no look up tables ) in syncmodular back in 2003 , which was later ported over to reaktor core .
And I am also pretty sure that the primary modules in reaktor/generator ( pre-core ) are calculated

[Taika-Kim]

But were they oversampled? And by how much? The question isn't if you can do that (since a saw wave is just a straight line), but if they are musically useful. Since if you don't do the extra math to do BLITs or whatever, or oversample a lot, there will be audible aliasing especially on the high notes.

[Ah_Dziz]

I am enjoying the grid immensely it has very low aliasing compared to almost every synth I've ever used and the waves in the oscs and lfos are incredibly easy to manipulate to get more "analog" flavor. Between the ability to fiddle with phase drift and pitch instability and then playing with some harmonic distortion and feedback you can make very very dense and solid sounding oscillators. The same feedback and distortion tricks work wonders for the filters (which were the least pleasant sounding part of the system to me at first). I am also having a great time modulating some of my old favorite vsts with the grid and the silly functions you can make it spit out. It and my Nord G2 are my two go-to spots for odd sound design these days. Honestly though, I still use zebra for 99 percent of my synthesis needs. If they would add some larger arrays I would be a happy camper. I had just made a incredibly dirty version of a wave table synth with the current array modules when they released their own wave table stuff.

[pdxindy]

The new Wavetable Osc in the Grid is a fine addition. Then there are the stereo options added to some modules. The Grid is almost as fast for me as various VST's for sound design!

[Q9000]

What a great topic and there is some discussion about DSP already, so let me step in:

What I don't like about the current Grid implementation is that it's not possible to build feedback loops with less than N samples, where N is the block size. This ****s. It just means that it is impossible to build certain DSP constructs which need tight delay lines, such as waveguides, comb filter, etc.
All just because they (probably) implemented it in a certain way where the Grid Elements work with blocks with N samples.

So as I see it "The Grid" is just to glue together Generators and Effects to get compositions, not to build fundamental DSP constructs.
They may just miss the boat for stuff like physical modelling where this functionality is required.

I personally don't care if the workflow is A+ if I am unable to realize basic DSP functionality. Yes the functionality can be found in other software, but then one needs to glue together fundamentally incompatible building blocks (VST/VSTi).

BitWig is a great DAW, don't get me wrong, but it can't replace some VST's with some specific functionality (to me).

One other point which I miss is that one can't host plugins(VST) inside "the Grid".

[pdxindy]

I personally don't care if the workflow is A+ if I am unable to realize basic DSP functionality.

Bitwig's Grid is obviously not for you.

I own Reaktor and M4L and I don't have a clue how to build something in either of them, even after putting a bit of time into it they both remained opaque. In the first 30 minutes of trying the Grid I was already building stuff I was happy with.

The Grid is awesome for me... and I am glad it does not do feedback loops, cause otherwise it would be massive CPU suck. There are Reaktor Blocks ensembles where 1 note can overtax my cpu. In comparison, I can easily get 24 or more voices of polyphony in the Grid.

I figure the Bitwig devs will add something like a modal resonator module and/or a waveguide module at some point.

[Noumena]

The Grid is not to build DSP primitives, but to assemble the modules that are provided. It is a modular environment, after all. The feedback limitation is a limitation, for sure, but so much else is afforded by the architecture that the cost/benefit or limitation/open calculation is pretty good. Ultimately everything is going to be limited vs a C++ compiler, no?

And just for a sanity check, people generally are not building comb filters with their Eurorack: they buy the primitives in modules and they patch them.

And you can effectively host VSTs and arbitrary chains of effects in the Grid. It's a bit of effort, but it works very well (and allows some flexible (if buffered) feedback signal flows. https://www.youtube.com/watch?v=Kx6mOos85yE&t=524s

I've used this and the grid's ability to modulate VST parameters with complex logic and timing processors to such great effect that even if the grid didn't make sound it would still be the best thing going. BUT! It does make sound--and what you can do with an oversampled, stereo, polyphonic w voice stacking modular environment with this particular set of modules is pretty remarkable. I would pick the poly/stacking vs some optimized (but still not perfect, is it is dsp) feedback implementation every time. I've been trying and never completing the below patch in Max4Llive for a couple of years... this took 15 minutes.

Screenshot 2020-12-10 233920.png

[Q9000]

[/quote]

The Grid is awesome for me... and I am glad it does not do feedback loops, cause otherwise it would be massive CPU suck.

Only when it's badly programmed, they may just JIT the code inside the feedback loop to some good (machine code) program, but yes this is hard to do and I can't really expect that from anyone .

The Grid is not to build DSP primitives, but to assemble the modules that are provided. It is a modular environment, after all. The feedback limitation is a limitation, for sure, but so much else is afforded by the architecture that the cost/benefit or limitation/open calculation is pretty good.

The restrictions of some "composition system" still matter, I can build low level DSP stuff in KRETS for example just fine.
My point is that the limitation exists just because the vendor wanted it to exist, because it's not part of their requirements.

You mentioned C++ and the toolchain(compilers), I don't want to program in a programming language without looping constructs for example.
Bitwig's Grid is nothing else, it's a visual programming language without (explicit) looping or recursion, etc.

Ultimately everything is going to be limited vs a C++ compiler, no?

Not every possible program.
I already mentioned a relativly efficient way how to handle it with the runtime of the DAW/plugin in question.
There are other ways to provide more flexibility, for example building blocks which execute programs.
Some VCV modules do something in this direction (evaluating user provided functions with many inputs and one output at audio rate).
Other programs limit the flexibility to only constructs which are possible to describe with some visual programming environment (Reaktor, I am looking at you) (this was already discussed somewhere else in the internet, so I am not the only one who has a issue with it).
I personally would like to have both, but that's just me.

Some people are just asking for more flexibility which isn't provided by certain tools.
The question is always if it's possible at all (it is), the demand for it and who/which company provides the tools.

Sure it's possible to program anything in a turing complete programming language (C++) if one had the time/money/knowledge/intelligence, this wasn't my point!
I get that I am asking to much from current technology (Bitwig in this case).

[whyterabbyt]

The Grid is awesome for me... and I am glad it does not do feedback loops, cause otherwise it would be massive CPU suck. There are Reaktor Blocks ensembles where 1 note can overtax my cpu. In comparison, I can easily get 24 or more voices of polyphony in the Grid.

No. Feedback loops don't intrinsically increase CPU usage.

And you'll maybe find that the reason those Reaktor blocks take more CPU is because they avoid simpler single-sample delay feedback loops for more complex calculations (ie those things known as Zero-Delay Filters)

[Q9000]

And you can effectively host VSTs and arbitrary chains of effects in the Grid.

This isn't hosting VST's inside the Grid, it's a ugly ugly hack which is (mis)using DC offset as a signal source etc.
Sure, it can even run windows inside a VST, but this doesn't mean that it runs directly inside the Grid.
Sure one can hack around limitations, but then it looses some of it's advantages (good workflow) with bad workflow in this case.

[Q9000]

Plus I wounder if it's possible to modulate the parameters of the plugin with a signal from inside the Grid, probably not because it has to "cross a boundary" (out of the grid, back in again).
It's just bad design if you ask me.

[pdxindy]

Plus I wounder if it's possible to modulate the parameters of the plugin with a signal from inside the Grid, probably not because it has to "cross a boundary" (out of the grid, back in again).
It's just bad design if you ask me.

You cannot directly modulate a plugin parameter from inside the Grid... It's not bad design... you are trying to make it something it isn't instead of working with what it is. There will eventually be a Midi Grid device which will do that.

I don't believe there is any practical reason for hosting VST's inside the Grid. It's mainly just wankery. Wanting to have no limitation for the sake of having no limitation.

Anything I want to do with VST's I can already do with Bitwig devices and modulators outside the Grid. Bitwig devices and modulators is already a powerful modular arrangement for working with VST's.

[Q9000]

>I don't believe there is any practical reason for hosting VST's inside the Grid.
Mainly for composing synthesis and effects provided by VST's / VSTi's.

>Wanting to have no limitation for the sake of having no limitation.
Well only if one doesn't want to use some synthesis methods which aren't provided by the built in synths, such as additive synthesis (like in Loom 2) or physical modelling (like in products from AAS, etc).

>Wanting to have no limitation for the sake of having no limitation.
Yes I like flexibility in certain places because limitations of my creativity by some artificial constraints isn't that good.
I see them everywhere, it's terrible.
Meanwhile I have to try to hack my way though this current mess with "glue" software like "Element", just because BitWig and Ableton don't allow to route signals between plugins(VSTs) with a graph.
Yes, one can hack their way around these limitations too, by using instrument racks etc. But this doesn't work for loops (there it is again).
I had one patch in Element where I had a feedback loop, this was supercool and allows for creative effects (custom reverb feedback loop).

I would additionally need to use for example Krets for custom low level DSP algorithms, or write some C++ code, all because software which is supposed to do it is either to expensive to me (MAX, a billion reverb plugins) or doesn't exist.

I guess I need to get used to hack around or not doing it at all because it's to cumbersome.

[pdxindy]

My creativity is not limited by constraints. The world always has constraints. Creativity is not hindered by that. I can make fresh new sounds with Bitwig and various VST instruments and effects from now until the day I die and never run out of new creative possibilities.

Maybe Reaktor is good for you.

For me, The Grid is my sweet spot. I'm not a coder.