Containers within the Grid

Came here to suggest this! Thanks!

3 Likes

@oo_oo welcome, feel free to vote if you like this feature suggestion :slight_smile:

1 Like

Thought I had by liking it, just now seeing the vote button. First time using a site like this but I’m learning haha. Thanks for pointing it out!

2 Likes

I hadn’t used this forum software before either. I’m really enjoying it so far. It feels refreshing compared to some of the more long-standing forum software

Yes, that this isn’t possible creates lots of hassle and spaghetti patches. To reuse code invented for other patches is extremely complicated and basically you don’t do it…
I envision that an encapsulated patch will open up as soon you go to help. But you might need some user interface as well. That would lead to a solution that could be useful in another context, mainly providing a userinterface in the device area…

2 Likes

I agree that a user interface is a crucial part of containers in the grid. I imagined something like a series of input and output modules, so you could have whatever ins and outs you need, as well as macro knobs directly on the container device, so you could have only the parameters you want available on the container itself. I think other visual aspects, like oscilloscopes/displays, custom knobs/sliders and a place to load a background image, would all be useful in the creation of custom modules via the container.

1 Like

this could help

Would love to see this feature!

1 Like

The other thing I haven’t seen mentioned in connection with Containers within the Grid is “technical debt”. Much has been made of Bitwig’s relatively young age and how this has given the devs a chance to start again, as it were, and write things well and plan for the future. All of these things I see as avoiding “technical debt”.

Surely, then, we need to have a degree of modularity to the way that Grids are written. Nobody is after a fully-blown Object-Oriented approach, just two or three levels of sub-modules, to add some sanity to the more ambitious creations. I’me sure that the Bitwig devs could come up with something that would give the necessary flexibility but with the ease of use and intuitiveness that characterises the Grid, and indeed Bitwig as a whole.

1 Like

The main reason I want this is it completes the composition model in the grid. A grid to me is a Lego block, and right now I can keep making Lego blocks, but I can’t compose them into larger Lego blocks that I can then reuse easily.

It’s just such an important feature it has to be done

Surely, then, we need to have a degree of modularity to the way that Grids are written. Nobody is after a fully-blown Object-Oriented approach, just two or three levels of sub-modules, to add some sanity to the more ambitious creations. I’me sure that the Bitwig devs could come up with something that would give the necessary flexibility but with the ease of use and intuitiveness that characterises the Grid, and indeed Bitwig as a whole.

It seems like a logical progression. We have both building block type modules ( for example the logic modules and math modules), as well as full fledged multi feature modules ( like the oscillators, filters and LFOs). So, you can build things in a programming type way, as well as normal modular synthesis. But, it gets really messy having it all on one screen, and not being able to really organize things well.

I mentioned in the description that I think this effects cpu performance too, because The Grid seems to require a lot of cpu for the visual graphics. I notice that complex patches push the cpu meter a lot higher when their windows are open, compared to when audio is only running through.

Once we get Containers, it will make it way easier to save, re-use and share sections of Grid patches. It will also allow for endless possibilities of new custom modules.

I use the Grid now for most of my synth, sampler, and sequencer patches, and it is my favorite modular environment to use. I think it is really well designed. It is intuitive, fun to use, and sounds great. But it’s main limitation compared to the others is that users can’t make custom modules. Containers would really open that up. More building block type modules would also, or something like Pure Data Grid Block would really open a can of worms.

I’ve mentioned before too, that I think the logical progression of this would be a suite of panel/visual modules, so we can make custom interfaces. Things like custom buttons and sliders, background images, waveform displays, customizable sequencers, and more. Eventually, maybe we could even get something like “stacked macros” in Reaktor. Those allow you to switch the views for different modes in a patch. Anyway, I’m rambling on, but my main point is that this seems like a logical progression for The Grid, being that it already has fully formed “eurorack” style modules, as well as simple building blocks. This can really join both of those in a more usable way, and open up huge possibilities for new types of modules in the Grid. This and “slicing in the sampler” are the 2 main features that I really want to see.

1 Like

Hello,

After reading the post above I thought I’d post an, admittedly low-quality, mock up of how I always imagined this feature would look like.

Having custom inferfaces would be cool, although as a first step I think it would be simpler to have it like this:

Basically, in this way we would be opening a grid within the grid. If that is not possible, It could be just a single sub-level of grid.

I’ve put input and output dots as well. Possibly we would be able to have multiple such, but for the sake of keeping it simple there is only one of each.

1 Like

but how is it different from just putting Grid into nested chain of another Grid?

Not different at all :sweat_smile:

I would still love to aim to be able to customize the interfaces of containers. Simply having a Grid window within the Grid seems limiting if we really want to create custom instruments, effects, sequencers ect…

For example, for sequencers, I would like to be able to load my custom sequencers without having to look at all the spaghetti, and just see the necessary elements to program a sequence. That would make them a lot more intuitive for using in patches. They would be able to be loaded just like the basic sequencers that are already included, instead of having to open a separate grid window to program the sequencer.

Or for example, with something like custom waveshapers, I would only like to see the necessary parameters with an oscilloscope, and have the necessary inputs and outputs, so I can just use my waveshapers just like the ones that are included.

Another example is that there are lots of types of modules that we might want for improving the look and feel of our patches. And, we can’t expect Bitwig to add everything we want. Like, I would love to have a modulation matrix with a simple and clear UI, so I could have less cables all over the place, and less forgetting what modulators are sent where. That wouldn’t be hard to make if I had panel options like “drop down menus” to use on the interface of the container. A clear and simple modulation matrix in combination with all the rest of our patches being contained within containers would really improve the look and feel of large patches.

A lot of the included modules could be thought of like containers. For example, the oscillators in The Grid have many extra features than you would get with something like the simple building block oscillators in Reaktor. So, as containers get developed. I think it would be very cool to make different types of oscillators than the included ones. This would be especially powerful if we get something like
Pure Data Block And, if we have the ability to create custom interfaces, then we could use them in exactly the same way as we use the included oscillators. That would lead to Grid patches that are a lot more intuitive and usable than large large patches with tons of spaghetti to get lost in.

Anyway, I’m totally rambling on about this, but hopefully it makes sense why I would like to aim for us to be able to have containers with customizable interfaces. Like I mentioned in the description, my original hope with this was to get something like “Macros” in Reaktor.

1 Like

x.iso

15. Feb.

<but how is it different from just putting Grid into nested chain of another Grid?>

The number of connections it could have, the readability of a patch, the real estate a patch needs in the grid. 1000 things come to mind.
I am programming in Max for almost 30 years. Without encapsulation you could not even think about complex patches. Its the main point in any programming environment. Reuse code. Code once use it multiple times…

1 Like

I was referring to specific implementation, which is not what I’d expect from container module

I’ve been wanting to suggest this for a while.

Since Im working for years in node based environment I can insure it’s a completely different level.
USING containers you can have a clean and Modular structure of the patch

I didn’t ask this in context of idea of a container module, I asked about specific implementation proposed.
I’m perfectly aware how sub-patches or containers work in more traditional modular environments, but Grid is different in few ways, so I’m still not sure how to replicate it in a way that makes sense for Grid.

In other modular environments it’s common thing to have inputs and outputs of different types of signals: audio and data maingly, mostly also different types of data, like array or even bitmap.
In Grid though, we have everything in audiorate, there’s no true arrays yet, no other types of data either. inputs and outputs Grid operates with have to do with upper level stuff like stereo pair that device receives or hardware in/out, and interpretation of midi/note signals as inputs and then the Note output.
So, I think that container module needs to break apart from that a bit and have unique set of arbitrary input and output modules, that would only be available in container editor, as it would make no sense for Grid on the device chain level. Those arbitrary in/out modules then could be assigned names and would appear on the UI of the module you edit, so you can put as many as needed that way. So far so good, but what about polyphony? Surely, one of the perks of container/sub-patch is ability to also stack it (and not get limited at 5 stacks either) and address different ‘voices’ in it separately if needed. We don’t even have modules that could let us address voices directly in regular patches, so that’s a whole another can of worms to deal with. Introducing something like Array type signals as well would help with this though. But all in all, I can understand why this takes forever to implement if they even plan to do it at all.