Let‘s speculate about 6.0

[] Peter:H []

The problem with languages like JavaScript, python, and lua is they aren’t particularly great at real-time audio processing because they’re interpreted and garbage collected.

Well there is LuaJIT

and it can call C functions and use C data structures
https://luajit.org/ext_ffi.html

but I don't see why they'd do any of this, it kind of defeats the purpose of grid.

LuaJIT is still garbage collected because garbage collection is a pretty fundamental attribute of a language. So that’s still not ideal.

And yes, calling C via FFI works because… you’re calling code written in a non-garbage collected language. So you see how that’s a cop-out answer?

It doesn’t defeat the purpose of the grid, it compliments it. Don’t worry, nobody is trying to take the grid away from you.

I use Luajit via Protoplug. Luajit itself is already quite good for the computations. when you add complementary lua modules which are written in C and some FFI, like the fft lib which comes with protoplug, it's quite usable
Anyway, luajit is not interpreted like lua. it's on the fly transformed into native code. And I think that is true for the Nitro language which is the scripting language inside of bitwig. I think Nitro works like NIs reactor works: Users assemble modules on the ui but the backend then compiles it to nitro and then finally to assembly ...
If we'd get a ~gen for Nitro backed by an appropriate API that would open the door for many cool things ... while bitwigs revenue stream might suffer if users can add considerable native bitwig extensions themselves. But how cool would it be to do a slink filter as native module like they did this max4live device for ableton, https://hypnusrecords.com/shop/p/slink

[coroknight]

The problem with languages like JavaScript, python, and lua is they aren’t particularly great at real-time audio processing because they’re interpreted and garbage collected.

Well there is LuaJIT

and it can call C functions and use C data structures
https://luajit.org/ext_ffi.html

but I don't see why they'd do any of this, it kind of defeats the purpose of grid.

LuaJIT is still garbage collected because garbage collection is a pretty fundamental attribute of a language. So that’s still not ideal.

And yes, calling C via FFI works because… you’re calling code written in a non-garbage collected language. So you see how that’s a cop-out answer?

It doesn’t defeat the purpose of the grid, it compliments it. Don’t worry, nobody is trying to take the grid away from you.

I use Luajit via Protoplug. Luajit itself is already quite good for the computations. when you add complementary lua modules which are written in C and some FFI, like the fft lib which comes with protoplug, it's quite usable
Anyway, luajit is not interpreted like lua. it's on the fly transformed into native code. And I think that is true for the Nitro language which is the scripting language inside of bitwig. I think Nitro works like NIs reactor works: Users assemble modules on the ui but the backend then compiles it to nitro and then finally to assembly ...
If we'd get a ~gen for Nitro backed by an appropriate API that would open the door for many cool things ... while bitwigs revenue stream might suffer if users can add considerable native bitwig extensions themselves. But how cool would it be to do a slink filter as native module like they did this max4live device for ableton, https://hypnusrecords.com/shop/p/slink

If you’re using C modules then the COMPUTATION IS NOT DONE IN LUA, ITS DONE IN C. Jesus Christ. Hey guess what, it’s not as much of a problem when you call out to another f**king language.

And LuaJIT is interpreted and it is garbage collected. The compiler compiles parts of your lua code into native code, but LuaJIT still has an interpreter, and lua as a language is still garbage collected.

But that’s not what I was talking about anyways, I said it’s garbage collected which is separate from interpretation/compilation. Golang for example is 100% compiled but also garbage collected. Separate things.

Great you use lua in protoplug, good for you. Maybe other plugin devs should switch from C to lua… oh wait that’s stupid because C is going to get you way better performance and no garbage collector so fewer audio glitches, especially in performance intensive code.

Maybe I suggested a better language because it would allow us to do more complex shit? Crazy idea.

Nitro is a completely different story because it’s CUSTOM BUILT FOR AUDIO PROCESSING. Gee maybe nitro doesn’t have these issues because it was designed from the ground up for audio???? No that can’t be right /s

[tumface]

If you’re using C modules then the COMPUTATION IS NOT DONE IN LUA, ITS DONE IN C. Jesus Christ. Hey guess what, it’s not as much of a problem when you call out to another f**king language.

And LuaJIT is interpreted and it is garbage collected. The compiler compiles parts of your lua code into native code, but LuaJIT still has an interpreter, and lua as a language is still garbage collected.

But that’s not what I was talking about anyways, I said it’s garbage collected which is separate from interpretation/compilation. Golang for example is 100% compiled but also garbage collected. Separate things.

Great you use lua in protoplug, good for you. Maybe other plugin devs should switch from C to lua… oh wait that’s stupid because C is going to get you way better performance and no garbage collector so fewer audio glitches, especially in performance intensive code.

Maybe I suggested a better language because it would allow us to do more complex shit? Crazy idea.

Nitro is a completely different story because it’s CUSTOM BUILT FOR AUDIO PROCESSING. Gee maybe nitro doesn’t have these issues because it was designed from the ground up for audio???? No that can’t be right /s

That sounds very angry, and you might want to reconsider how this sounds, when there is incomplete knowledge. You can't dynamically allocate from virtual memory (heap) on an audio thread in the middle of rendering audio without risking stalling, even in C. The garbage collection aspect is irrelevant for soft-realtime audio computations. You can write code for LuaJIT that doesn't allocate on the audio thread, the same way you'd have to do it for C.

[coroknight]

You can't dynamically allocate from virtual memory (heap) on an audio thread in the middle of rendering audio without risking stalling, even in C.

Where did I say you can’t write bad C code? Where? No shit Sherlock, of course you can write C code that stalls.

[tumface]

You can't dynamically allocate from virtual memory (heap) on an audio thread in the middle of rendering audio without risking stalling, even in C.

Where did I say you can’t write bad C code? Where? No shit Sherlock, of course you can write C code that stalls.

No, you said that LuaJIT isn't good for audio because it uses garbage collection, compared to a language that doesn't, like C. I pointed out that it doesn't matter if it has garbage collection, because the same things that induce garbage collection -- virtual/heap memory allocations -- can't be done in C in the audio thread, either, so that aspect doesn't matter, and that your vitriol is uncalled for.

[_leras]

You can't dynamically allocate from virtual memory (heap) on an audio thread in the middle of rendering audio without risking stalling, even in C.

Where did I say you can’t write bad C code? Where? No shit Sherlock, of course you can write C code that stalls.

[] Peter:H []

The problem with languages like JavaScript, python, and lua is they aren’t particularly great at real-time audio processing because they’re interpreted and garbage collected.

Well there is LuaJIT

and it can call C functions and use C data structures
https://luajit.org/ext_ffi.html

but I don't see why they'd do any of this, it kind of defeats the purpose of grid.

LuaJIT is still garbage collected because garbage collection is a pretty fundamental attribute of a language. So that’s still not ideal.

And yes, calling C via FFI works because… you’re calling code written in a non-garbage collected language. So you see how that’s a cop-out answer?

It doesn’t defeat the purpose of the grid, it compliments it. Don’t worry, nobody is trying to take the grid away from you.

I use Luajit via Protoplug. Luajit itself is already quite good for the computations. when you add complementary lua modules which are written in C and some FFI, like the fft lib which comes with protoplug, it's quite usable
Anyway, luajit is not interpreted like lua. it's on the fly transformed into native code. And I think that is true for the Nitro language which is the scripting language inside of bitwig. I think Nitro works like NIs reactor works: Users assemble modules on the ui but the backend then compiles it to nitro and then finally to assembly ...
If we'd get a ~gen for Nitro backed by an appropriate API that would open the door for many cool things ... while bitwigs revenue stream might suffer if users can add considerable native bitwig extensions themselves. But how cool would it be to do a slink filter as native module like they did this max4live device for ableton, https://hypnusrecords.com/shop/p/slink

If you’re using C modules then the COMPUTATION IS NOT DONE IN LUA, ITS DONE IN C. Jesus Christ. Hey guess what, it’s not as much of a problem when you call out to another f**king language.

And LuaJIT is interpreted and it is garbage collected. The compiler compiles parts of your lua code into native code, but LuaJIT still has an interpreter, and lua as a language is still garbage collected.

But that’s not what I was talking about anyways, I said it’s garbage collected which is separate from interpretation/compilation. Golang for example is 100% compiled but also garbage collected. Separate things.

Great you use lua in protoplug, good for you. Maybe other plugin devs should switch from C to lua… oh wait that’s stupid because C is going to get you way better performance and no garbage collector so fewer audio glitches, especially in performance intensive code.

Maybe I suggested a better language because it would allow us to do more complex shit? Crazy idea.

Nitro is a completely different story because it’s CUSTOM BUILT FOR AUDIO PROCESSING. Gee maybe nitro doesn’t have these issues because it was designed from the ground up for audio???? No that can’t be right /s

I was talking about (a) the JIT principle by using Luajit as wittness and (b) the principle of having performant APIs or "callouts" to complement a jit'ed language with performant dsp atoms ... that makes it usable. ~gen is working ... isn't it. And I want to back it by personal experience rather than theoretical bs. I didn't say we should get luajit in bitwig ... though it would be fun. I just added some facts to the whole picture of a "~gen" module discussion.
You are way too angry ... no use to talk to such negative people anymore.

[Hanz Meyzer]

Here is why actual composing in Studio One is much more easy than in Bitwig:

- Better overview, more info at once, no space wasted
- You can align the pianoroll zoom with the arranger zoom, so that you can quite easily see what's going on on the other track at the same exact position (not using annoying workaround pianoroll layers)
- Studio One clip labels do not waste space, it's a transparent addition, the whole space is used to display actual note information
- You even have some tools like "select first note of each measure" or so.
- You have chord detection, follow chords, follow scale etc.
- You have actual step recording

Also Studio One could be improved when it comes to accessibility here, but already these little features make it much more easy, at least for me. Try a DAW which provides alignment of the pianoroll with the arranger. This is very helpful, and also such a simple feature. I think Cubase can do that, too....

[OdoSendaidokai]

Linux Wayland Support
for having finally Drag and Drop again
.... after years.

[JHernandez]

Here is why actual composing in Studio One is much more easy than in Bitwig:

- Better overview, more info at once, no space wasted
- You can align the pianoroll zoom with the arranger zoom, so that you can quite easily see what's going on on the other track at the same exact position (not using annoying workaround pianoroll layers)
- Studio One clip labels do not waste space, it's a transparent addition, the whole space is used to display actual note information
- You even have some tools like "select first note of each measure" or so.
- You have chord detection, follow chords, follow scale etc.
- You have actual step recording

Also Studio One could be improved when it comes to accessibility here, but already these little features make it much more easy, at least for me. Try a DAW which provides alignment of the pianoroll with the arranger. This is very helpful, and also such a simple feature. I think Cubase can do that, too....

-That's what eventually makes it appear cluttered in my eyes. Here is where less is more imo. Bitwig somehow manages to look cleaner in a full session (if you close tabs/panel,ect) imo, though it still has too much info for my taste. But I understand it's a subjective preference.

-I don't actually use the piano roll that much. I def try to stay out of it. I record performances directly to audio as much as possible, unless I have to record something I can't physically accomplish. For this I tend to use hardware/instrument's sequencer > then direct to audio. I do use Bitwig's Drum Machine/Samplers a lot, but for these I drag the midi out of my sequencer of choice and bounce to audio asap. I do wish Bitwig had my sequencer of choice though.

I get that a lot of people record/input/work with MIDI in the piano roll. Typically with plugins, in an loop, for what seems like an eternity. Again, it's a preference, or perhaps limitation in some cases.

-Again, working mostly direct to audio. Just give me a clean layout. I think it's weird when clip labels overlap the waveform/midi info. It breaks the flow visually imo. In my mind that translates to clutter. I prefer the label above the waveform/midi like BWS does it. Pic related.

ugly_labels.png

^That is ugly imo^

- That sounds useful for midi stuff.

- I prefer not to use such tools as they hinder my quick flow style of working. However, should something happen to my mind and or hands in the future I will no doubt appreciate such tools. Pretty sure Bitwig will have these tools soon anyways. Also, there's plugins.

- That can be useful to have natively. Again, sequencer issues.

I tried to like S1. Mainly for it's capable, but very ugly sequencer, but I just can't. S1 just doesn't Bitwig. Also, man is that DAW ugly.

[Hanz Meyzer]

Hehe Well, I like Studio One, since it is very straight forward in visual appearance and UX. I also would prefer an option to completely disable the clip labels, completely useless for me. Don't need labeling of clips on a track. Makes no sense, use the space for note display instead.

[JHernandez]

^ It's all subjective of course.

I'm with you on clip labels. I'd appreciate an option to toggle them on/off.

[BazJacuzzi]

- You can align the pianoroll zoom with the arranger zoom, so that you can quite easily see what's going on on the other track at the same exact position

This would be so good to have

[Hanz Meyzer]

I think what I am trying to say:

Bitwig does not seem to think of any kind of "context" when it comes to the user interface. It all are neat little units on its own, but don't know anything of each other. But context is absolutely most important when it comes to composition.

Studio One, Cubase try already to provide a bit of contextual info, like, what's on the track playing next to each other? Can the user easily see the rhythmical structure? If the Bitwig team would try to think in context, there could be so, so many little improvements... e.g. a shortcut of playing only the notes under the current position (without starting playback)... Or actually highlighting the position on the other tracks, or even highlighting the currently playing notes on the other tracks. Or visualizing transients and note starts already in the arranger... etc. etc.

It seems to me that aligning the pianoroll zoom and position to the sequencer currently is the peak of the iceberg regarding conceptual ideas in DAWs... I wish there was more...

And this is a topic where an oldschool tracker actually is way, way better than the usual pianoroller (besides all the obvious disadvantages). You can very simply see the rhythmical structures of all the tracks next to each other (not on top of each other), and if you are used to it, also the notes.

[Dionysos]

Bitwig's editor has a track mode and can display all or a selection of track contents at the same time. I find it a bit clunky to use, but IMO you're making your pet missing feature out to be a big conceptual issue that I don't think it really is in Bitwig.

I do agree with the general point that integration of features is key, and where Stepwise for example completely fell flat for me as setting it up just isn't straightforward.