- This topic has 22 replies, 4 voices, and was last updated 9 years, 9 months ago by
.
-
Posts
-
Hi
– “luaPanelLoaded” and “luaPanelBeforeLoad” are not working in
restricted exported versions ? they work only in the full version for me
– problem with one panel: “midiMessageChannel” is changed via LUA but the modulator still sends on the same channel and the
modulator change its midi channel if it receives any channelized msg ( if I send ch1 it get ch1 etc…) the rack attack panel uploaded works nice and uses similar
method
Tried “midiMessageChannelOverride” but it fails.
on the pic i have 2 “midiMessageChannel”
one I want in red and other that is the real valueThe item in red says “MidiMesageChannel”, it’s lacking a “s”. Surely on some lua code you wrote it wrong and it created a new field named MidiMesageChannel.
About point one, I agree that in exported versions there is something wrong at starup and probably related to some of those scripts.
Thank You Dasfaker ! you have the eye of the snake
just need to delete and re create changed mods
I send correctly now
But I still don’t understand why I can’t receive different midi chnls correctly .If I have 3 mods with cc17 ch:1 , 2 and 3
they move all and change their midi chnls to ch:x when ctrlr receive a cc17 ch:xFor the first point I don’t have trouble with full exported version (tried exe not dll for now) the problem is with restricted version only
The edit mode force me to create some scripts to kill nil
or assign correctly current tabs values at startup + my panel initializes most editor mods at start up and keep only VSTexported mods and “system” mods
But in restricted instances nothing happens.Thank you again
You’re welcome
The incoming cc channel issue is happening here, too.
Hi, I’ve managed to solve the issue.
The solution is to use a Multi message.
Just put the controller number and it works fine.MIDI
Message type…Multi
Override…….No
Channel……..2
Midi CC……..X (not in use)
Midi Value…..X (not in use)
Multi Message..CC,Direct,Direct,1,-1,That’s it.
But the problem remains in the app!MVXSynths
R3 / MOX6 / Electribe2 / Electribe R MkII / Electribe MX / K4R / BCR2000 / XStation61 / XStation25 / Virus Rack / Chameleon / Proteus 2500 / RM1X / KN2600Using this method works opening the panel in Ctrlr, but the exported instances fail, they only transmit cc messages on channel 1.
Atom, please take a look here.
I’d like to know what’s the issue here exactly.
When you change the Panel MIDI OUTPUT CHANNEL you apply that value to all modulators (since the midi channel is stored inside each MIDI object). Is that wrong, is that the issue. Should the panel MIDI CHANNEL change NOT change the actual MIDI message channel?
The problem is that once set the channel a slider should send a midi CC, if you send the same midi CC from any other channel, all the sliders sends in that channel, no matter which is the panel channel.
Is something like autolearn, but in a very undesirable way.MVXSynths
R3 / MOX6 / Electribe2 / Electribe R MkII / Electribe MX / K4R / BCR2000 / XStation61 / XStation25 / Virus Rack / Chameleon / Proteus 2500 / RM1X / KN2600If you receive a cc in channel 1 for example, all modulators with the same cc react to the incoming message, ignoring the channel they have.
Using the multi message instead of cc message works in a .panel instance, but in a standalone instance, all cc modulators transmit in channel 1, ignoring the channel they have assigned.
The first issue i can try to fix.
The second one is tricky, everytime you change the panel output channel all Midi messages assigned to modulators get their channel changed (this is why after opening an standalone instance they send on channel one, the channel gets changed on load no matter what it’s set to).
So now i can add an option for a panel not to apply the MIDI OUTPUT CHANNEL value to all modulators everytime it’s changed AND/OR add a Lua method that gets called everytime the channel gets changed in the panel so you can plug in your own behavior for that event. Maybe you have other suggestions on how to deal with this issue ?
So now i can add an option for a panel not to apply the MIDI OUTPUT CHANNEL value to all modulators everytime it’s changed
I think this should be the way to go, just change the midi output channel to those modulators with “Override panel MID channel” activated and leave the rest as they are.
Yeah will do.
I also added some code to compare incoming midi for channel. So if a modulator has a different channel set and the panel is setup to receive ALL channels only the modulator with the matching channel will change.
Atom, what about the first zeoka’s question?
– “luaPanelLoaded” and “luaPanelBeforeLoad” are not working in
restricted exported versions ? they work only in the full version for meI have similar problems with all exported instances.
So now i can add an option for a panel not to apply the MIDI OUTPUT CHANNEL value to all modulators everytime it’s changed AND/OR add a Lua method that gets called everytime the channel gets changed in the panel so you can plug in your own behavior for that event. Maybe you have other suggestions on how to deal with this issue ?
I also added some code to compare incoming midi for channel. So if a modulator has a different channel set and the panel is setup to receive ALL channels only the modulator with the matching channel will change.
This issue isn’t solved yet. I attach an example panel with 3 mods controlling cc10 on channels 1,2 and 3. Every incoming cc10 message on any channel is received by modulator with ch.1. The others don’t react. I’ve tried every in/out channel combination in the MIDI menu but with no luck.
Yeah i tested it now and it works as expected, however you did not the checkbox to override the MIDI channel for each modulator.
With that checked, each of the sliders reacts only to the MIDI channel it has defined, with the panel set to receive messages on ALL channels.
No, it doesn’t work here with channel override active and all channel input.
In fact, with these settings, once a ch1 message is received all modulators move
- The forum ‘Programming’ is closed to new topics and replies.