Here is a Duplex app I created. It is very largely based on the mixer app, but I added the possibility to control any dsp parameter with the pan pots. You can browse the dsp devices directly from your controller. It displays a window which acts like the lcd display I wish my BCF-2000 would have. This window lets you see what parameters you are controling. More detailed instructions are in the attached zip file.
I have only tested it on a BCF2000, but since it is based on the mixer app, it should work with other controllers as well. The “lcd display” is built to display 8 tracks. I will make a more generic version if you people like this app.
And of course, all commentaries, bug reports and feature requests are welcome!
Cool. Thanks for sharing! Would be great if we somehow could try to integrate most parts of this to the duplex core, so everyone can use this without having to exchange or hack some of the duplex Lua file.
Would you be interested in try to do so, cooperating with us?
Danoise: What do you think about adding this to the duplex core?
If you are, here are some thoughts on how we could do so:
add encoder pushes to the Behringer XMLS (also the BCR). I simply forgot them. This is easily done and won’t conflict with anything.
your app basically is a combined “mixer and effect” app which also communicates with another app, the LCD view. Instead of specializing one app for a specific controller, your device configuration should launch multiple applications (Mixer + Effect apps). As soon as we have the encoders in the XML, this should be easy to do in order to get the basic effect controlling added.
now the tricky part, the LCD view. We need to find a way to “attach” the LCD view to existing apps. Basically we only need a one way communication here: The LCD is readonly, so it only has to get notified, attach itself to the relevant parts of already running apps. To do so it could simply be an app like Effect + Mixer are.
I think danoise already had something like inter-duplex-app-communications in the queue, for a navigator app. The navigator would be able to change, control multiple running apps. With the Renoise Lua API, this could be done by adding Observables for each thing other apps may be interested in, so anyone (apps, devices, whatever else) can attach to and change app properties - from anywhere.
An LCD will be very hard to do generically, so this should always be a device specific class?
We anyway do need something like an LCD view in duplex later, to completely support the Mackie Control and others, so this definitely would be a great thing to start a solve. At least think about.
On the subject of the LCD view, I’ve been thinking about this as well. Although, the way I was considering it started from a different root. I realized that some duplex uis are meant to represent the state of the device, but if you have a device which presents it’s own state, then the view is useful only as a testing platform/for someone who does not own the device. This train of thought led me to considering “performance views” for applications, whereby the developer has the option/ability to include a view for each function and communicate with the app.
A generalized version of this, inside of Duplex, would be incredibly useful. As expressive as many of our controller ui’s are, much of the time we need text and numbers rather than a scaled variable ui element.
I am willing to help out with any of the code or organization/ideas… whatever really. Duplex, and the Lua scripting environment have been incredibly useful/enlightening to so far, so I would love to have the ability to contribute if the size/scope leads to a group effort.
Sure I’d be glad to cooperate with you on this! I also think this should be part of the duplex feature.
This is hard to do since as far as I know, the device configuration is static, the app can’t modify it. And different apps can’t share the same controls. As I want the same pots to control the pans and the effects, I have to handle this inside the same app. Of course with inter-app communication and dynamic configuration it would be different…
About the LCD, I can easily make it display more or less tracks, according to the controller’s configuration file. To push it much further, it could follow the device’s configuration and display a cell for every knob or button the device has, like the duplex window, but with display instead of sliders and stuff. But I think this would lead to enormous lcd views for big controllers, which is no good idea… Best thing in my opinion would be to have a device specific configuration file for the lcd.
If we have a lcd configuration which specifies a knob for each lcd cell, the main app should have observables for what parameter is mapped to this knob. The lcd app would then display it. I can’t think of a better way to do this at the moment…
Three weeks without internet connection at home is getting tedious. But it’s GREAT to see so many new projects spawn from the duplex core!
I think it sounds really cool. I have to download this beast and give it a spin, but I do agree with you on the ‘keep apps small and managable’ aspect, although this makes re-usable LCD control/application more tricky to pull off.
And yes, inter-app communication is an important part of this. An obvious use for a LCD is to display the parameter currently being modified - and this sort of thing requires that the LCD display is able to bind itself to any/all applications.
I say, let’s discuss this some more, because inter-app communication would be much like the meta-devices: you have 100s of uses for them, once you get to know what they do. Here are a couple of things that I would like to be able to do:
Switch between presets in realtime from the controller (instead of using the mouse/browser)
Globally control something like an ‘automation record’ for Duplex applications
Display context-based information in external displays (LCD, etc.)
Provide methods for capturing and playback of internal events in Duplex
This window lets you see what parameters you are controling. More detailed instructions are in the attached zip file.