Containers within the Grid

Community Wishlist
, , , ,
1

Similar to “macros” in Reaktor, this would allow us to clean up our Grid patches, and have only the necessary parameters displayed on the interface. Plus, we could easily save sections within our patches as a module with whatever ins and outs we want, as well as macro knobs to control the devices within the container module.

A mockup by @oo_oo :

image
image1920×934 85.5 KB

What problem(s) would this feature resolve?

  1. This would give cleaner interfaces to Grid Patches
  2. This would allow the saving and sharing of custom Grid components (just like macros in Reaktor)
  3. I assume this could improve cpu usage, because I have noticed that large Grid patches use a lot more cpu when their window is opened, than when only audio is coming through. So I assume they require more cpu process the graphics. Therefore, if we consolidate large clusters of modules that don’t need to be seen, into containers, that should improve.

How does this feature fit in Bitwig as a product?

The Grid is a core diferentiator of Bitwig. This feature would greatly improve what can be made with the Grid, and lead to a large user library of custom patches with unique interfaces.

Is there already an alternative way to achieve this on Bitwig?

No

Could it be implemented using Bitwig components or APIs, without Bitwig team’s support?

No

Could it be provided by a VST or something else reasonably integrated with Bitwig?

No

Are there other products that offer this feature?

Other modular environments, like Reaktor and Max do, but they are very different than the Grid.

Relevant links (optional)

10 Likes
2

6 posts were split to a new topic: [Draft discussion] Containers within the Grid

4

Came here to suggest this! Thanks!

3 Likes
5

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

1 Like
6

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
7

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

8

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
9

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
10

https://www.reddit.com/r/Bitwig/comments/rc2gbq/grid_modulation_to_control_everything_you_can/

this could help

11

Would love to see this feature!

1 Like
12

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
13

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

14

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
15

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:

image
image1920×934 85.5 KB

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
16

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

17

Not different at all :sweat_smile:

18

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
19

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
20

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

21

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