It’s not possible to midi map the parameters of a DSP device once it’s part of a Doofer or Splitter.
I am unsure if this is intented behaviour.
Version 3.5.3
1 Like
I know I am able to macro them but I wanted to know if there are other ways.
yeah i’ve been meaning to look into whether i could use splitters to have specific devices, yet still modify, with hardcoded midi mappings, the device parameters.
i’m not sure if it’s gonna be possible to do, but i hope there’s a way. would be cool.
yeah:
there’s no route for selecting a device and getting it’s information from within the Splitter - so that’s any kinda modification of the parameter of the device within the Splitter out of the question, unfortunately.
UNLESS if one were to start doing some sort of dynamic controlling, i’m talking a really brittle and hacky method of assigning one of the 16 macros to control a specific parameter within the Splitter device, but that would require one to both hijack macro16 and point it to a device that you know is there, and then unbind it.
it might work, but i dread to think how problematic it would be to maintain.
actually, now that i assigned a macro, it looks like this
<Name>Macro 4</Name>
<Mappings>
<Mapping>
<DestChainIndex>0</DestChainIndex>
<DestDeviceIndex>0</DestDeviceIndex>
<DestParameterIndex>2</DestParameterIndex>
so that looks like it’d be doable, but then you need to absolutely know what you’re doing and what the device is…
i mean, i’m starting to see how this could be done, with like a LUA GUI that lets you choose devices and their parameters and then write Macro Knob XML stuff that hits those specific ones, but we’d pretty much be injecting macro knobs, live, to the splitter device. could be a total logistical nightmare.
it might be doable tho. but i’m still looking for a usecase for this, and i feel like there are easier things to research and accomplish than this one.
<DeviceChain0>
<SelectedPresetName>Init</SelectedPresetName>
<SelectedPresetLibrary>Bundled Content</SelectedPresetLibrary>
<SelectedPresetIsModified>true</SelectedPresetIsModified>
<Devices>
<DistortionDevice type="DistortionDevice">
<SelectedPresetName>Init</SelectedPresetName>
<SelectedPresetLibrary>Bundled Content</SelectedPresetLibrary>
<SelectedPresetIsModified>false</SelectedPresetIsModified>
<IsMaximized>true</IsMaximized>
<IsSelected>true</IsSelected>
<IsActive>
<Value>1.0</Value>
<Visualization>Device only</Visualization>
</IsActive>
<Threshold>
<Value>5000</Value>
<Visualization>Device only</Visualization>
</Threshold>
<LpOrClamp>
<Value>16000</Value>
<Visualization>Device only</Visualization>
</LpOrClamp>
<WetOut>
<Value>13</Value>
<Visualization>Device only</Visualization>
</WetOut>
<DryOut>
<Value>0.0</Value>
<Visualization>Device only</Visualization>
</DryOut>
<GateOrFilter>
<Value>0.0</Value>
<Visualization>Device only</Visualization>
</GateOrFilter>
<Type>
<Value>1.0</Value>
<Visualization>Device only</Visualization>
</Type>
</DistortionDevice>
</Devices>
1 Like
Just map Macros to parameters and map midi to macros
It’s a form of data encapsulation
you’re suggesting something that puts a direct limitation of 16 midiknobs whereas people might want to do way more than that, and in a more fluid freeform way.
i get that you think you’re proposing a solution, but it’s a very limited scope one.
ok.. let me try and communicate.
let’s have a usecase, where someone has a pre-configured Splitter, with 8 or 16 macros set up for controlling something very specific.
then they want to add some additional devices to the mix, and control them, also, in a very specific way. they can’t do it, without removing some of the 8-16 macro knobs and replacing them with others. the ideal solution is to allow direct control of within-doofer, within-splitter, device parameters, and then thus allow for controlling them without having to destroy macros that pre-exist.
i hope you understand what i’m saying.
Complication…Use hydra between
i don’t understand how hydra is supposed to help with this situation.
adding more complexity to try to get rid of a limitation sounds pretty brittle.
hierarchical automations…A tree
Only 3 parameters on the trunk can make variations on each leafs
Controlling each leafs independently is completely silly
Reinforce the logic of the architecture
Automation processors:
Hydra,Formula,Meta mixer…
Actuators:
Tracker commands,Key tracker,Velocity tracker,Signal follower…etc…
when someone says “controlling each leaf independently is completely silly” - i know they’re not prepared for a conversation of the value of it
and they’re just shooting from the hip.
3 Likes
Yes, 16 way is too low to automate a drumsynth for example🙂
But for a an FX chain it is sufficient…If you need more for that purpose,you are either an idiot or a genius…But in general,genius want to simplify complex
But for melodic work…It’s different…From a simple melody,you can made it more complex
A simple ‘4 notes’ melody can be fractionnized
To me it seems to have been overlooked; or determined that macros is the way.
The MIDI map function could traverse the widget tree making all parameters mappable.