Pleas don't make me drag cables all over the place. I hate that. If you're going down the spaghetti route, at least add the functionality from Bitwig's grid as showcased in the video from 3:27
If you don't want to watch it, here's a summary.
1) dragging a module on the input or output connectors of another one automatically connects the cables
2) Cables are stereo by default
3) dragging a module on top of the other one replaces it.
4) dragging a module on an input that's already connected while holding a modifier automatically inserts a mixer/merger module. (not shown in the video)
5) double clicking and dragging the output of a module allows to move all connected wires at once.
6) (in addition) the first module added is automatically connected to the input and output.
Yeah please no spaghetti like modular synths (curved and/or hanging cables). I’m all for “wired” connections but a bit more rigid with straigth (angled) lines and maybe some kind of grid snapping when connecting.
I love modular, but to the folks that don't like them, why not to continue using the default method if modular connections appear instead of wishing no cables?
I love modular, but to the folks that don't like them, why not to continue using the default method if modular connections appear instead of wishing no cables?
The problem with fully modular spaghetti, like Max or MetaPlugin, is this:
You cannot create this structure using REAPER pins, but it's generally permitted by freeform spaghetti UIs. So if and when there's some kind of cable UI for FX chains and containers, I agree with Phazma that something more mediated with a clear flow direction and (maybe) optional manual cabling would be ideal.
If the flow is unambiguous, you only need cables to patch things which don't follow the prevailing path. I think that Zebra does this pretty well with its matrix:
^^ seems like a feedback routing on first pic? Yeah this is some of the things that modular is unbeatable if one wants to do it.
Else he could use the pins. Modular would be for more advanced connections, or even simpler ones for those who like to see them all and are used to this view.
As a long time modular user, I don't mind any modular view, even though personally I prefer more the max/reaktor/metaplugin way.
cables could be hidden as well and to see the connection by hovering the mouse over them
^^ seems like a feedback routing on first pic? Yeah this is some of the things that modular is unbeatable if one wants to do it.
Exactly, you can't create feedback in a REAPER FX chain, so the freeform UI is deceptive. For this kind of signal chain, I definitely prefer the Zebra-style, where the flow is unambiguous, and you are visually dissuaded from trying to make illegal connections.
Exactly, you can't create feedback in a REAPER FX chain, so the freeform UI is deceptive. For this kind of signal chain, I definitely prefer the Zebra-style, where the flow is unambiguous, and you are visually dissuaded from trying to make illegal connections.
Definitely looks easier , especially to the folks that are not used to modular.
Yeah please no spaghetti like modular synths (curved and/or hanging cables). I’m all for “wired” connections but a bit more rigid with straigth (angled) lines and maybe some kind of grid snapping when connecting.
Depends on the interpolation of those lines/cables, linear could show up as straight lines while bezier more "curved"
Max has a cool option as I remember correctly to clean things up and create automatically "corners" to the straight cable routings in order to pass next to the modules and not above them, and make the whole structure look cleaner.
I can think of many situations where someone would want feedback routing. Just turn the connection orange or something - add option to ignore feedback protection on that route. No reason to go all Apple and assume users can’t handle it.
There are various visual approaches to perform spaghetti routings. Please avoid using poor examples to depict them.
Up until now, none of you have been able to execute the subsequent routing task (image below) using the present system
Performing such routing with spaghetti routings requires less than 15 seconds, without any need for technical thinking. To me, this represents the liberty of creativity.
Spaghetti is simpler, more straightforward, and has boundless possibilities. Furthermore, it may be possible to create custom interfaces for spaghetti routing that do not necessarily have to look like spaghetti at all.
Spaghetti is simpler, more straightforward, and has boundless possibilities. Furthermore, it may be possible to create custom interfaces for spaghetti routing that do not necessarily have to look like spaghetti at all.
I can think of many situations where someone would want feedback routing. Just turn the connection orange or something - add option to ignore feedback protection on that route. No reason to go all Apple and assume users can’t handle it.
It's not about users not being able to handle it. Unless I am mistaken, you cannot create feedback routings using the current pin routing system (of which the UI would be a representation).
How about marking the previous fx when there is a following parallel fx, and automatically removing the marking when there is no following parallel fx? The "previous fx" in this context is just a normal fx which parallel fxs (the option "Run selected FX in parallel to previous FX" is on) follow, so it can't be marked in the same way (||) as the parallel fxs. Another indicator would be needed if it will be added.
Quote:
Originally Posted by FeedTheCat
E.g. when there is no previous fx and nothing is happening -> don't show the indicator.
Maybe the devs need to put the indicator even when there is no previus fx in order to clearly show the option "Run selected FX in parallel to previous FX" is selected on that FX.
How about marking the previous fx when there is a following parallel fx, and automatically removing the marking when there is no following parallel fx? The "previous fx" in this context is just a normal fx which parallel fxs (the option "Run selected FX in parallel to previous FX" is on) follow, so it can't be marked in the same way (||) as the parallel fxs. Another indicator would be needed if it will be added.
Agreed.
Quote:
Originally Posted by Suzuki
Maybe the devs need to put the indicator even when there is no previus fx in order to clearly show the option "Run selected FX in parallel to previous FX" is selected on that FX.
There's two ways to go about it, you can show the state of the option, or you can show what's happening (the effect of the option). Do we care about the state of the option if nothing is happening? I'd say not really, but yes, you can make an argument for both. I just prefer the latter.
There's two ways to go about it, you can show the state of the option, or you can show what's happening (the effect of the option). Do we care about the state of the option if nothing is happening? I'd say not really, but yes, you can make an argument for both. I just prefer the latter.
I'm not sure which I prefer, but in that case, a non-marked but option-selected fx should be marked automatically when it moved to a position next to a normal fx.
The benefit of "indicating the state of the option" would be that users can move option-selected fxs to wherever they take effect without checking the status.
Easy with plain old pin routing using the appropriate count of channels. Supposedly featuring multiple channel mixers.
Containers might help to make it slightly more strategic (combining (1/2), (8/9/10)) .
-Michael
I was just running through it in my head. I think 10 channels (5 stereo) is enough for this example. Splitting is accomplished by routing an effect's output pair to multiple pins. For things like this (I've been doing 1st order Ambisonic processing recently) I use the "Channel Mapper-Downmixer" for combining. It supports as many channels as the track itself does, and can do the required attenuation on re-combining.
Agreed. Parallel FX could also be visually connected in FX chain using nesting structure like in FX browser.
+1 for this.
One of the major issues is the inability to view the contents of the containers without opening them.
A hierarchical system similar to a tree structure would likely be great solution for this.
I am not against modular synths or feedback routing, I just want avoid things like these being possible:
This is a Max msp example. Surely with a bit of care you can angle cables and position modules more wisely and end up with something less confusing like this:
Still, in an example like Max msp (I've been using that software, though not super extensively), even if you tidy it up like in the image above, you end up with overlapping cables and it becomes a bit complicated to follow the signal flow and find the cable/connection you need.
What i am asking for is not restricting flexibility, but having a more grid like system, where you can't put FX just anywhere on the UI but have slots or some kind of grid where you can place them and have a system which automatically organizes connections in a way so that you can easily follow the signal flow.
I think the Studio One implementation so far is my favorite but what I don't like about it is that all FX are shown in the insert FX list as if they were routed in serial. I would prefer adding just a "Container" FX to the FX list or FX chain and clicking on that opens a UI like the Studio One "Routing" button where FX can be routed in parallel with splitters.
I think the Studio One implementation so far is my favorite but what I don't like about it is that all FX are shown in the insert FX list as if they were routed in serial. I would prefer adding just a "Container" FX to the FX list or FX chain and clicking on that opens a UI like the Studio One "Routing" button where FX can be routed in parallel with splitters.
That's a pretty nice visualization of a container I can get behind.
Having the container's content shown in the FX list could be a setting since I see the benefits of both.
You provided an unfair comparison as the max MSP example includes significantly more routings and far more complex than the others + someone probably didn't care about organizing it since he probably created a surface for this mess
BTW, I find it way more difficult/impossible to envision achieving something as complex as this using either a pin system or the current containers system.
However, I agree that it is important to have features for organizing routing, as well as creating custom surfaces to control crucial parameters within complex routing systems.
You provided an unfair comparison as the max MSP example includes significantly more routings and more complex than the others.
However, I agree that it is important to have features for organizing routing, as well as creating custom surfaces to control crucial parameters within complex routing systems.
True, the Max msp patches are more complex. But my point was, that with a system like in Studio One where FX snap to a specific position and connections are made automatically it would be impossible to create a mess like the first max MSP picture and it would take no extra work to make it look like the second max MSP picture (or actually even clearer than that).
Of course the automatic wiring of Studio One doesn't allow things like feedback routing, but it would be simple to implement in some way like right click the FX and choose a feedback destination from all available FX and it creates a connection in a different color or something like that. Yes, that would be a bit more work than just dragging a cable to the input of an FX, but IMO creating feedback routings should not be too simple anyway. And besides that I don't see what the S1 implementation lacks in terms of flexibility.
I haven't used FL Studio to produce my music in around a decade, but I still find it remarkably intuitive. The ability to create a patch with custom surface to manipulate all parameters within a patch is truly remarkable.
It feels like crafting your own synthesizer or machine where you have complete control over everything.
The routing process is quick and allows for creativity to flow on the fly and the custom surface takes it to the next level and give it a life of its own. every preset becomes a monster of creativity.
After creating a custom surface, you may not even need to view the routings if the preset is comprehensive enough.
PS- Of course there are things that could be done better in fl-patcher, but all in all it really is a monster that gives tons of inspiration.
BTW: Here is a similar preset (a bit more simple) that I created in REAPER with the current containers system.
The problem is that I can NOT get a whole picture of what's going inside this patch.. I need to enter every container to see what is inside.
vs
FL-patcher
where I can get what is going on in this patch in one single view.
I really like most of the ideas, I don't really mind what the devs will choose as long as it is not the pin connector system and I will easily see what is done in the routings.
Maybe it would be a good idea to start with a default routing system that has the best flexibility, and then let the scripters create different interfaces for the routings later on.
Maybe it would be a good idea to start with a default routing system that has the best flexibility, and then let the scripters create different interfaces for the routings later on.[/QUOTE]
That's my feeling. It should be possible now for MPL and others at his level to totally wow us.
A quick thought that Containers with Macros / Mod Panel would nicely solve.
I love this EQ, I just wish it had a wet/dry as in "I want more / less of this curve, overall".
Using the Reaper native Wet/Dry knob doesn't work here because this plugin phases against the dry.
But I'd love to assign each of the Gain knobs to a Macro, and that knob scale the values together, achieving the same goal of "more/less of this curve". Turn the macro right, all the gains increase together. Turn it left, reverse effect.
And as extra finesse, having more than just linear mappings from a knob to a parameter - imagine assigning the different crossfade shapes as an alternative to linearly mapping a knob->param.
Man, these containers are so dang useful already, but I'm still having trouble wrapping my head around them.
I'm really hoping you can keep the momentum going on this and make some progress ASAP.
I think that the completion of the lanes feature is necessary for the developers to direct the appropriate level of attention towards the routings feature of fx containers.