ArrayArrayArrayArray BrainModular BrainModular Users Forum 2017-01-07T00:01:43+02:00 https://brainmodular.org/forums/app.php/feed/topic/5638 2017-01-07T00:01:43+02:00 2017-01-07T00:01:43+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36572#p36572 <![CDATA[Yet even more VST suggestions]]>
I was throwing around some ideas in this thread about a module designed to wirelessly interact with vst's from anywhere within a workspace http://www.sensomusic.org/forums/viewtopic.php?id=5584. A way of envisioning this is that a vst and all of it's relevant data is available within usine similar to how a bus is but with two way flow, access to multiple targets simultaniously and various data types all consolidated to be accessible from a single multi-function module.I think if I wanted to take the time to elaborate, after accomplishing some ridiculously complex patching tasks along these lines, I have a pretty solid idea now of what functions would be best suited for such a module. Maybe possible on a user module level without changes to underlying Usine code, I do not know. Something like this I assume should not require a major rewrite of core Usine functionality.

My original post in this thread is more directed as suggestions for slight expansion of the current functionality, but I more than welcome continuing discussion on how the concept of more in depth integration of vst's and parameters manipulation / integration could be accomplished.

Statistics: Posted by gurulogic — 06 Jan 2017, 23:01


]]>
2017-01-06T13:26:15+02:00 2017-01-06T13:26:15+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36571#p36571 <![CDATA[Yet even more VST suggestions]]>
But there really needs to be a way to address a single parameter programmatically (i.e. not by patching cables!)
That gets down to the whole nature of Usine - everything is patched (apart from the use of IML).
The wiring up thing is a blessing and a curse. Since everything is treated as a continuous signal, discrete messages (for example midi messages) have to be put on the wire and then blanked a bloc later to avoid multiple messages on the output. Doing that manually is a real pain. This could be addressed by having "message" wires as well as "signal" wires. I believe some other DAW has that.

The other thing is if you create a fairly complicated GUI with lots of visual components in Usine, they all have to be wired up which is quite a pain - especially doing scripting when the previous connections are lost if you add a new parameter in the middle. SDK user modules are better in that respect since the wiring is kept (presumably it is stored against parameter name rather than parameter number). In comparison doing such a GUI in Javascript is easy since its done programmatically without having to wire up everything.

The programmatic method in Usine of course is IML, but it is really an internal protocol. The global namespace and different internal parameter names, etc. mean that it is horrible to try to use, and often goes wrong. It should be replace by something better. But anyway, can IML be used to address a single parameter without patching cables ?

The advantage with the cables is that they define the interface between modules, which stops rogue modules from writing to random parameters and breaking the workspace. Perhaps the new HH3 multi-wire bus could be used in some way, to allow a single "multi-wire" input to a module without needing individual wires to be connected. You'd want the promise that using that bus inside a single patch would never add latency I suppose.

Another idea would be a system that allows messages to be sent between modules without any wiring. You could possibly use OSC for this (?) but its not really intended for that.

Simon.

Statistics: Posted by sm_jamieson — 06 Jan 2017, 12:26


]]>
2017-01-06T08:20:03+02:00 2017-01-06T08:20:03+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36569#p36569 <![CDATA[Yet even more VST suggestions]]>
A vst ID would be useful too, although I create unique names by appending the rack number to the vst name. Works as long as you don't use the same vst twice in the same rack.

Statistics: Posted by woodslanding — 06 Jan 2017, 07:20


]]>
2016-12-30T14:52:45+02:00 2016-12-30T14:52:45+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36537#p36537 <![CDATA[Yet even more VST suggestions]]>
-Name outlet for vst. Can be done with IML but a name outlet for vst factory (and caption) name would be useful.

-Vst ID. Would be nice if each vst could output an unique (short) ID to assist in advanced parameters interfacing, especially useful in the case of more than one of the same vst in a patch / workspace.

-Probably a long shot, but if receiving a parameter value could block output of that parameter to array outlet and if controlling a parameter from the vst UI could block input of that parameter. Sort of an internal stop if changed. Would really help with managing feedback loop issues when looping params arrays to and from the vst.

-- lots more suggestions to make vst interfacing even more robust in HH, but this is all probably already well enough discussed in the forums ;)

Statistics: Posted by gurulogic — 30 Dec 2016, 13:52


]]>
BrainModular BrainModular Users Forum 2017-01-07T00:01:43+02:00 https://brainmodular.org/forums/app.php/feed/topic/5638 2017-01-07T00:01:43+02:00 2017-01-07T00:01:43+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36572#p36572 <![CDATA[Yet even more VST suggestions]]>
I was throwing around some ideas in this thread about a module designed to wirelessly interact with vst's from anywhere within a workspace http://www.sensomusic.org/forums/viewtopic.php?id=5584. A way of envisioning this is that a vst and all of it's relevant data is available within usine similar to how a bus is but with two way flow, access to multiple targets simultaniously and various data types all consolidated to be accessible from a single multi-function module.I think if I wanted to take the time to elaborate, after accomplishing some ridiculously complex patching tasks along these lines, I have a pretty solid idea now of what functions would be best suited for such a module. Maybe possible on a user module level without changes to underlying Usine code, I do not know. Something like this I assume should not require a major rewrite of core Usine functionality.

My original post in this thread is more directed as suggestions for slight expansion of the current functionality, but I more than welcome continuing discussion on how the concept of more in depth integration of vst's and parameters manipulation / integration could be accomplished.

Statistics: Posted by gurulogic — 06 Jan 2017, 23:01


]]>
2017-01-06T13:26:15+02:00 2017-01-06T13:26:15+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36571#p36571 <![CDATA[Yet even more VST suggestions]]>
But there really needs to be a way to address a single parameter programmatically (i.e. not by patching cables!)
That gets down to the whole nature of Usine - everything is patched (apart from the use of IML).
The wiring up thing is a blessing and a curse. Since everything is treated as a continuous signal, discrete messages (for example midi messages) have to be put on the wire and then blanked a bloc later to avoid multiple messages on the output. Doing that manually is a real pain. This could be addressed by having "message" wires as well as "signal" wires. I believe some other DAW has that.

The other thing is if you create a fairly complicated GUI with lots of visual components in Usine, they all have to be wired up which is quite a pain - especially doing scripting when the previous connections are lost if you add a new parameter in the middle. SDK user modules are better in that respect since the wiring is kept (presumably it is stored against parameter name rather than parameter number). In comparison doing such a GUI in Javascript is easy since its done programmatically without having to wire up everything.

The programmatic method in Usine of course is IML, but it is really an internal protocol. The global namespace and different internal parameter names, etc. mean that it is horrible to try to use, and often goes wrong. It should be replace by something better. But anyway, can IML be used to address a single parameter without patching cables ?

The advantage with the cables is that they define the interface between modules, which stops rogue modules from writing to random parameters and breaking the workspace. Perhaps the new HH3 multi-wire bus could be used in some way, to allow a single "multi-wire" input to a module without needing individual wires to be connected. You'd want the promise that using that bus inside a single patch would never add latency I suppose.

Another idea would be a system that allows messages to be sent between modules without any wiring. You could possibly use OSC for this (?) but its not really intended for that.

Simon.

Statistics: Posted by sm_jamieson — 06 Jan 2017, 12:26


]]>
2017-01-06T08:20:03+02:00 2017-01-06T08:20:03+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36569#p36569 <![CDATA[Yet even more VST suggestions]]>
A vst ID would be useful too, although I create unique names by appending the rack number to the vst name. Works as long as you don't use the same vst twice in the same rack.

Statistics: Posted by woodslanding — 06 Jan 2017, 07:20


]]>
2016-12-30T14:52:45+02:00 2016-12-30T14:52:45+02:00 https://brainmodular.org/forums/viewtopic.php?t=5638&p=36537#p36537 <![CDATA[Yet even more VST suggestions]]>
-Name outlet for vst. Can be done with IML but a name outlet for vst factory (and caption) name would be useful.

-Vst ID. Would be nice if each vst could output an unique (short) ID to assist in advanced parameters interfacing, especially useful in the case of more than one of the same vst in a patch / workspace.

-Probably a long shot, but if receiving a parameter value could block output of that parameter to array outlet and if controlling a parameter from the vst UI could block input of that parameter. Sort of an internal stop if changed. Would really help with managing feedback loop issues when looping params arrays to and from the vst.

-- lots more suggestions to make vst interfacing even more robust in HH, but this is all probably already well enough discussed in the forums ;)

Statistics: Posted by gurulogic — 30 Dec 2016, 13:52


]]>