Dump Request and multitimbral operations

[dasfaker]

I’m beginning to test the panel in a multitimbral environment, and I’m having a problem to manage the dump request of each channel.

I have the same panel opened two times, and each panel is assigned to a different channel. When I make a dump request on channel one, for example, it goes to the two panels, as the incoming sysex message has no channel identifier. But I’ve assigned a variable in Lua when the dump request is sent to differentiate both channels and still don’t work, the midiMessageReceived method of both panels catch the dump so I’m having some doubts.

Are variables assigned in Lua common to all panels? If I have a variable filter_cutoff in both panels, do they share the value or are independent?

Can the global variables k0… be accessed trhu Lua somehow? It seems that if I use k0 in Lua it’s not the same k0 of a sysex message.

Thx

[atom]

well no, variables are not shared across panels (and never should be), you are getting the message for both panels cause SysEx message dont have a standard MIDI CHANNEL byte that i can rely on, you need to figure it out on your own in your LUA script.

[dasfaker]

Thx for the reply.

What about the second question? Can I access global variables k0… thru Lua?

[atom]

i think i didnt expose those methods to lua, but it’s not a problem i’ll do that with the next build (hopefuly tomorrow), still they won’t be shared across panels.

i can add a small set of functions to access data across panels, but i wanted to avoid that for as long as possible, this will raise a set of problems to solve later on. but if you feel it will be useful
i’ll do that.

[dasfaker]

Ok, fantastic.

About data crossing between panels, it could be really interesting, but right now it’s a feature I don’t need. The little problem with the dump request was really easy to solve. Thx.

[msepsis]

I’m glad you said that was a low priority das ” title=”Smile” /> I was failing to see the benefit of setting ctrlr to be able to speak between panels – when you finish your panels you will be mostly using them within your daw, where for most practical purposes you would only have one panel assigned to a MIDI track anyway…

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[dasfaker]

Yes, in a sequencer it’s not necessary. I was thinking of standalone mode in a panel that could open/close/call other panels.

Imagine a panel that handle multis/combis of a synth. You have each part (normally 16) on screen with the parameters of each multi part and deal with them. Now imagine you click on any part, and automatically Ctrlr opens the panel to edit this part. Right now I have to open a panel to edit the multi, a panel to edit each part, configure inputs and outputs, or have 16 panels stored and configured to handle each part, or make a mega panel containing all of this. A bit confuse for a user not involved in creating panels.

The idea is to have to work with only one panel, and from this panel manage all aspects of the synth, (parts, multis, songs, config paramters, switch from patch/voice/program to multi/song/combi, etc).

[msepsis]

yeah, believe me im pickin up what you’re puttin down – i see where you’re going but it may be more practical to limit your panels to only speak to one "part" or midi channel per instance unless all you plan to do is record audio out of the synth you’re controlling in standalone mode.. As hard as it is to pull yourself out of ctrlr standalone mode I highly recommend you spend some time working with the panel as a vst in your DAW as that’s really the intent of building these panels.

I’m partly playing devils advocate here as I’m as addicted as I think you are to building functionality to control as much as possible from these panels.. but when using these panels in a DAW you’ll only be speaking to one channel per ctrlr instance anyway, right? Really identifying that fact helped me save a ton of time by staying focused on the core intent of the panel instead of programming every possibility known to man.

Maybe what you want to do is control the synth through one big massive ctrlr panel in standalone mode and record the midi data to appropriate MIDI tracks in your DAW? Even in that situation – You’ll still have to do the same thing – create a MIDI track per part of your multi(1-16) in your DAW so you have some way of capturing and recalling the MIDI messages sent from the ctrlr. Most musicians using a multitimbral synth in a DAW are fairly versed in the track-per-part concept, so I don’t think that would confuse any users.. nor is it more work – really you just need to set it up once, save a session/project template in your DAW and go from there.

I do get what you’re trying to do but I think it’s probably best to get ctrlr matured to a solid stable release first ” title=”Smile” /> I can understand why atom was pushing off interpanel communication for as long as possible.. and I just don’t think there’s any reason to even think about going there.. If you need two instances of any vst you just load another instance of it in another track in your daw. Same should go for ctrlr, imo.

Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

[dasfaker]

I agree with you, the main use of Ctrlr is as a vst in a sequencer. But this level of programmable control of any synth makes my imagination fly far away, specially for live situations.

I’ve been working in a setup that could allow me to use all the synths in a similar way as a keyboard arranger. I use Ableton for midi routing, creating some devices in MaxforLive, and almost all I want to do can be done, but Ableton lacks sysex!! Ctrlr is an ideal host to make a environment that could control all the midi gear from one place at the touch of a button, where I could save, load and edit any setup, and with a custom interface, because yes, I’m a fanatic of interfaces.

Such control would need inter panel communication to allow certain modularity, but as I said it’s not a must. I’m really happy with what Ctrlr does right now.

[atom]

actualy i was wrong, setGlobalVariable() and getGlobalVariable() are available in the CtrlrPanel class and should work, i just didnt update the API docs online i’ll fix that in a moment

[Author]

Posts