Hmm, your device is sending a NoteOff essentially immediately after the NoteOn - and then another NoteOff 32 ms later. It should not be doing that.
Then a solution would be to “fix” your controller using a Gig Script. But we have to be sure that it is always sending the same sequence each time you act on it.
I didn’t read this full topic again, but I was wondering why the midi port of you controller is an IAC port and not the controller native MIDI port… Is it the same if you monitor the controller native MIDI port?
I use a hardware controller which is relative new from makepro x audio. This controller can only be used when a certain software is running which is called “Glue”. So in Glue it is configured that IAC Port 10 is the Outport of the hardware controller.
Nice controller, the only thing I don’t understand is the price.
Is there something you could configure in this Glue software or should we really think of a Gig Script for fixing this unbelievable note on/off/off behavior?
By the way did you use any kind of MIDI sync for widgets assigned to this controller?
What do you mean with MIDI sync for widgets assigned to this controller?
Right now I can not configure it in Glue because it seems that the Software is a kind of beta-Version. Theoretically it is very flexible, but right now there are a lot of issues, so it would be very helpful to fix this with a Gig Script if possible. Maybe in two months the Glue Software can really shine, but as I said right now there are some issues with it.
Apart from that the controller looks and feels very very nice, but it is definitely not cheap
Frankly, I’m not sure it’s a good use of GPScript to fix a problem that should be fixed by the developer of the product causing the problem. One might be able to use some timing detection but that kind of thing gets tricky.
Perhaps try beating them up to fix their faulty product
Or maybe just send it back and buy something reliable.
This is perhaps the best answer.
You can buy something reliable + spare some money. It’s way overpriced.
Yes, at this unbelievable price level we should at least get the perfection. I am pretty sure there is nothing this device can do that an Icon Platform M+ can do within GP.
But I agree it has a fancy look, it is very sexy.
@ZappaFrank, could you please show us what’s happen in the Global GP Monitor when you press a button, wait 1 sec and release it? Even if is a shame to fix such a device with a Gig script, that is probably doable…
Thank you that you are willing to help. I will have the Global GP Monitor tomorrow for you.
I think the perfection will come some day. It seems they are doing it the Microsoft way (products matures in the market), not the Steve Jobs way (product has to be more than perfect when it gets into the market)…
Did you press a second button? The one sending B6 looks ok. But the button sending F-1 has a problem where it sends the note simultaneously with the note on.
You want to take the risk using this controller?
No I didn’t press a second button. I would take the risk to use this controller.
On the other hand I could really understand if you and David san don’t invest more time into this
because I am aware of the fact that the controller at this stage is only to a certain degree usable and I have other controller who can do this job. If you have something like a filter script at your disposal then I would be interested in it. First just to learn something from it and second it could solve the problem with my “Luxury Controller”, but as I said, this whole thing is not a serious issue for me. So if you want, just forget it, live goes on…
What message is learned by the widget?
@ZappaFrank from what I see here, we have one single usefull note on message while the rest is scrap. In particular there is no message sent when you release the button after 1sec. So the only thing we can do with this is to control a widget in latching mode using the “Momentary to latching” option in the MIDI tab of the Widget properties. And you will also have to edit manually the MIDI message to make it correspond to the first note on message sent by your controller.
No need to use a Gig script for this as there is no button release information to filter out or to convert here.
OK, thank you very much.
Let’s suppose I got something like a plugin or an external midi device that supports step trough as you say. What MIDI Commands would I have to send in that case?
Let’s take for example the Boss GT-1000: If I use the scriptlet and send the MIDI to the GT-1000 MIDI IN I can step trough my GT-1000 presets. If do the same for the Nord Stage, I can step through the presets of my Nord Stage. So it seems that this scriptlet works really well in an universal way. I would just be curious what is under the hood of this scriptlet and would it be possible to achieve the same results with just MIDI Commands without the scriptlet? Or in other words: I would like to see if I can achieve the same results outside of GP with a Software like Bome MIDI Translator or whatever MIDI Tool.
Here you see a screenshot of an increase button someone made in Bome MIDI Translator.
I have no experience with this software. I just wanted to show this as an illustration of on example of an incremental function.
As far as i am aware, there is no real “increment” or “decrement” command in the MIDI architecture.
These commands actually imply a relative movement from any given value - means in regards of a program change: No matter which program number (i.e. patch on an external synth or a plugin as well) might be active, it would add or subtract from there…
But there is no way to “read” via MIDI, which program number is active.
MIDI rather works as a one way street, with just one cable from a MIDI-OUT to a MIDI-IN, there is no feedback coming over this cable if the send messages had an effect or not, or wether a sent value change had taken place or not… you just can send a message out in the good belief that it will do what you want.
I know that most synths have a pair of buttons which do exactly that, but to make use of these buttons (respecting their functionality) via MIDI or host automation, a synth had to have implemented a separate command for this (i.e. it could react on an incoming value of 127 on CC#100 with a +1 on the actual program number and on a value of 0 it could do a -1), but there are two things to take in account with that idea (even if such thing existed):
- This could be diffrent from synth to synth (or plugin)
- You still have no way to “read” from the synth which program number is actually active - so you could send a inc/dec to the synth, but you’d never know (midi wise) where you actually are.
Talking of this scriptlet:
The GP scriptlet will always start counting from a fix program number which is sent at the beginning - if you haven’t changed anything, it’s 1.
So because this PC (#1) is sent at the start, the script “knows” from where to count, and that’s all it does (with some extra functions).
You can simply test this if you open the plugin and manually change to patch #5…
Now go back to the panel… if it was a “real” increment/decrement, pressing the +1 button should change to the patch #6, but it won’t because of what i wrote above, instead it starts counting on 1 (as default) and then switches to patch #2 because your pressing the +1 button.
I don’t think that there is any way around this (but maybe i am wrong though).
The only improvement you could make, is another additional parameter to adjust the start value from where the counting would start.
As @schamass highlights, there is no such thing as a next/previous program change. They are absolute values: 0 to 127. So either the sender or receiver needs to specially manage this concept, because it ‘knows/remembers’ what it last sent/received.
In the case of the scriptlet, it is managing the process, because it stores what the last pc number it sent out.