Container FX Discussion

[mschnell]

Originally Posted by LugNut

Just plz,plz, include midi in these wiring schemes.

AFAIU, the Container fully supports Midi, as it simply is a complete FX chain inserted at a dedicated point.

-Michael

[Ozman]

In regards to the "no spaghetti" pleas, I think that the same information can visually be displayed in multiple ways. A simple button click or menu item click could switch between the current container view, nodal/wired view, modular or rack view, faceplate view, or any other view. The main part is the general mechanics be functional, and the display can at some point be optional.

[Phazma]

Originally Posted by Ozman

In regards to the "no spaghetti" pleas, I think that the same information can visually be displayed in multiple ways. A simple button click or menu item click could switch between the current container view, nodal/wired view, modular or rack view, faceplate view, or any other view. The main part is the general mechanics be functional, and the display can at some point be optional.

That is true but the thing is, the UI takes work to do and it appears to not be the favorite type of work for the devs. I think it is unlikely they will create several UIs for the same feature, just because different people like to see it in different ways.

What I think is more likely is that they will create the container and add features in such a way that scripters can easily access and modify the routings and provide whichever GUI they want for it (there will be wire based scripts, rack based scripts etc…)

[Vagelis]

What's not to like from spaghetti?

[vitalker]

Originally Posted by Vagelis

What's not to like from spaghetti?

They are fast carbs, which make you fat.

[UknownSource]

When considering consistency, a tree-based structure resembling tracks within tracks (folder levels for tracks + ability to create sends/receives etc).

Also utilizing schematic diagrams, similar to those used for tracks (with some upgrades), would be an optimal choice for ensuring consistency.

This decision appears to be the most consistent approach in my opinion.

[UknownSource]

Not exactly related but look at the new spaghettis that Sexan cooked for us
♡
https://forum.cockos.com/showthread.php?t=278176

[Ozman]

Originally Posted by Phazma

That is true but the thing is, the UI takes work to do and it appears to not be the favorite type of work for the devs. I think it is unlikely they will create several UIs for the same feature, just because different people like to see it in different ways.

What I think is more likely is that they will create the container and add features in such a way that scripters can easily access and modify the routings and provide whichever GUI they want for it (there will be wire based scripts, rack based scripts etc…)

This is exactly what I'd hope for, I'm seeing Sexan is doing, and it makes my almost shed a tear.

[Reflected]

Originally Posted by Ozman

This is exactly what I'd hope for, I'm seeing Sexan is doing, and it makes my almost shed a tear.

Lol I feel the same about Sexan's script.

It is my hope that the Cockos team will provide the necessary foundation codes for Sexan to enable him to develop an exceptional impressive wiring schematic system for the fx routings.

[todd_r]

I wonder if Reapers own FX container stuff will enable Sexan to continue his version?

**Attempts to summon Sexan**

[mschnell]

Originally Posted by Reflected

It is my hope that the Cockos team will provide the necessary foundation codes for Sexan to enable him to develop an exceptional impressive wiring schematic system for the fx routings.

I don't think there is anything missing (but only Sexan can decently comment on that). The Reaper API should provide all hooks to see and modify the routing (Track and FX, Audio and Midi (including FX parameter modulation), supposedly including the Reaper Control Path hooks with "Learn"ed links to parameters, and Midi Devices).

But the task to do a decently usable tool is utterly complex.
-Michael

[Suzuki]

Originally Posted by mschnell

I don't think there is anything missing (but only Sexan can decently comment on that). The Reaper API should provide all hooks to see and modify the routing (Track and FX, Audio and Midi (including FX parameter modulation), supposedly including the Reaper Control Path hooks with "Learn"ed links to parameters, and Midi Devices).

But the task to do a decently usable tool is utterly complex.
-Michael

Sexan already commented on this topic.

Originally Posted by Sexan

Regarding track routing it would need a modification and if new api is sensible enough could be added.
The biggest problem I had with previous FX Container is the audio passthrough which is always present if you uncheck the pins. There is an option to disable passthrough but as default its on and that was making big problems how to present the connection (and of course other limitations) since its disconnectes but audio is still passing.

Anyway maybe in some future but not on any priority list

mpl's view on the matter is also here.
https://forum.cockos.com/showthread.php?t=270810

[mschnell]

Hmm.

MPL considers:
"ability to natively receive/send audio and MIDI flow from/to some gmem idx memory entry"

Due to the basic concept of the DAW (per track CPU-threads) it is strictly impossible to do "realtime" (i.e. Audio sample time-stamp based) routing via gmem. Hence such considerations are pointless.
Maybe some other parts of his concepts might be worth considering.

-Michael

[Reflected]

we really need Justin/Schwa's help here.

[UknownSource]

Originally Posted by todd_r

I wonder if Reapers own FX container stuff will enable Sexan to continue his version?

**Attempts to summon Sexan**

Hahaha nice photo.

Super Sexan is great.
but we still don't have a good routing system for fx.

[UknownSource]

I wish Sexan will actually talk to Justin and Schwa and tell them what it needs to make it possible for him to create routings for fx.

[Meo-Ada Mespotine]

Moving the goalposts, huh?

First, you wanted FXContainers, you got FXContainers.
Now you want FXRouting, which is a different feature altogether.

I personally think, that the current implementation is all you are going to get. Take it or leave it.

[Reflected]

Originally Posted by Meo-Ada Mespotine

Moving the goalposts, huh?

First, you wanted FXContainers, you got FXContainers.
Now you want FXRouting, which is a different feature altogether.

I personally think, that the current implementation is all you are going to get. Take it or leave it.

Just to clarify, routings are indeed a crucial aspect of this topic.
The feature that we're discussing, which is a more customizable FX routing system, was actually a part of the original request for FXContainer functionality. In fact, it was the biggest part of the thread and many users, myself included, requested this feature specifically to make parallel routing more convenient and accessible.

While the current FXContainer feature is useful in its own right, it falls short of what we had hoped for in terms of routing capabilities. Adding the ability to see the map and to manipulate of the parallel routings would greatly improve workflow efficiency.

I appreciate the efforts of the developers so far and hope they will continue to improve this feature to better meet our needs.

Originally Posted by Ozman

This is a simple request for a Plugin Container.
It could contain any FX chain as a single FX instance.
As well as provide oversampling for the entire chain/instance.
This would be quite useful for the following:

- Mixing FX chains, FX chains for individual Tracks
- Easier organizing of FX chains, especially when multiple FX are used for actually
one "effect".
- Easily employable oversampling for ANY FX instance or chain (VST and JSFX alike).
- Moving group of FX up and down the FX chain can be made easier, being that any group of FX can be gathered into a single "FX Container" instance.


The GUI of this FX Container can be done in various ways.
I'm thinking, maybe a simple wired view (like Blender's Nodes, Bidule, ImageLine's MiniHost, DDMF's MetaPlugin, MPL's FX Wiring script, and Reaper's own Track Wiring View).

Please consider. I truly believe that adding such an FX container would be a improvement for MANY workflows.

- oz

[mschnell]

Rather obviously, special purpose (i.e. dedicated to those users who appreciate these) connection-GUI makeups will be a task for helpful script designers.

AFAIU, Reaper provides all functionality allowing for this.

-Michael

[Reflected]

Originally Posted by mschnell

Rather obviously, special purpose (i.e. dedicated to those users who appreciate these) connection-GUI makeups will be a task for helpful script designers.

AFAIU, Reaper provides all functionality allowing for this.

-Michael

Sexan and MPL clearly said that there are limitations in the foundation, so I'm not sure if it's possible.

[mschnell]

Originally Posted by Reflected

Sexan and MPL clearly said that there are limitations in the foundation

Hence a decent request might be to have the appropriate API functionality provided.

[Reflected]

Originally Posted by mschnell

Hence a decent request might be to have the appropriate API functionality provided.

If it were that simple, I guess Sexan would have already requested it and obtained it, after spending so much time trying to create that script

[mschnell]

Unfortunately I don't know what is lacking. so I can't comment / research.
-Michael

[UknownSource]

Originally Posted by mschnell

Unfortunately I don't know what is lacking. so I can't comment / research.
-Michael

Originally Posted by Sexan

Regarding track routing it would need a modification and if new api is sensible enough could be added.
The biggest problem I had with previous FX Container is the audio passthrough which is always present if you uncheck the pins. There is an option to disable passthrough but as default its on and that was making big problems how to present the connection (and of course other limitations) since its disconnectes but audio is still passing.

biggest problem is the passthrough but he also mention that there are other limitations

[Sexan]

Please don't spread misinformation.

What I've posted was the state BEFORE FX feature was even implemented and it was not the reflection on CURRENT STATE of Reaper. THEN there were no parallels, no containers, no feedback loops etc etc (the limitations).

Key word here is THEN and NOW.

Also I've said maybe in SOME future and its not on ANY priority list

[Reflected]

Originally Posted by Sexan

Please don't spread misinformation.

What I've posted was the state BEFORE FX feature was even implemented and it was not the reflection on CURRENT STATE of Reaper. THEN there were no parallels, no containers, no feedback loops etc etc (the limitations).

Key word here is THEN and NOW.

Also I've said maybe in SOME future and its not on ANY priority list

Please don't be upset with us for being so eager to have this feature.
In fact, I've even made donations a few times to support the development of this feature, to you and to other developers who have attempted it in the past.

I'm glad to hear that there's a chance for this feature to be created, and I hope that it will be given priority in the future. As someone who is passionate about this functionality, I would be more than willing to support it.

[Sexan]

Just wanted to make sure that what I've said is not taken out of the context.

[UknownSource]

My apologies, I thought there were still some limitations. Are you saying that the new FX containers now enable us to create it?

[Reflected]

I want to think that the current container is a beginning of something great and I also want to think that it will get some priority as it is a real fun and inspiring to use containers.