General

MENU OBJECT problem - works only on 1st tap

Started by octobersongs on .

Sign in or create an account to join the conversation.

19 posts

Topic starter
I've created a couple of Menu Objects with 5 or 6 items in each menu using the Custom Midi technique below and it works beautifully, except for one thing. One menu was for simple Edit menu items in Cubase (delete, copy, paste, etc.). Once an iPad/Lemur menu item had been selected, that item name (say, paste) would show on the closed menu and the data would have been pasted appropriately in Cubase. But if I wanted to repeat the paste to another location in Cubase, selecting paste again would do nothing. I would have to choose another menu item from that menu (like delete) and then reselect paste to complete the second paste action. Has anyone run into this before?

Thanks,
Joe


Softcore wrote:
Actually, there two ways to achieve this, considering you need a 127 CC value....

You can either use a custom midi out OR script. In the following examples both solutions are displayed - the menu otuputs on CC controllers 21-30 (10 options - notice the "selection+21" thing in both the solutions)
Short answer is you can't easily do it with menus. Since you didn't change the selection, Lemur doesn't send/do anything. If you want to be able to repeat certain operations, using a custom button object for those things (like pasting) would be the easiest/ quickest way.

There is probably some way to eventually get it to work using menus, but if your goal is a working app (versus the goal of deeply learning Lemur) use a button.
octobersongs wrote:Thanks for that. Thought there might be some script that could be added so that it would register that it had been tapped again. (Don't mind going a little deeper.)

jc

I played a bit this morning. There is a trick you can do; not sure if there's any long-term side effects.

If you have a menu of 10 items (selection returns 0-9), you can set the Menu.selection value to 10 in a script after doing an operation from that menu. For example, if you call a paste script when the user selects paste, by setting the Menu.selection value to 1 more than the max in the menu, it blanks out the display so that the user can pull down the menu and reselect the same option.

Some issues -- the menu display will blank out and this will not work if you have a full menu (32 items). NOTE - do not try setting the selection to -1. This will crash Lemur and force you to edit the script outside Lemur to change from -1 to something else.

I have a junk script attached that has a menu and a monitor. Select a menu option to see what happens and decide if it's something that can help.

Untitled.jzml
Thanks for looking into this oldgearguy.

Expanding on your script, is it possible to have none of the menu selections appear, as your "Option 3" does not? Would that allow you to reselect & re-execute any of the menu options? In this usage, it's unimportant for my last choice to show, so none of them need to appear. A text object could be placed over the menu object saying "file" or "edit". The monitor in you example wouldn't even be needed.

jc
octobersongs wrote:Thanks for looking into this oldgearguy.

Expanding on your script, is it possible to have none of the menu selections appear, as your "Option 3" does not? Would that allow you to reselect & re-execute any of the menu options? In this usage, it's unimportant for my last choice to show, so none of them need to appear. A text object could be placed over the menu object saying "file" or "edit". The monitor in you example wouldn't even be needed.

jc

I just had the monitor object to show that if you repeatedly selected option 3, it actually did something (as opposed to the default behavior of not doing anything), hence the simple counter.

Yes - if you redirected the selection value to 6 (in this case) after each selection, it would display a blank and allow you to keep reselecting the same option.

it's as simple as creating a script in the menu object set to: "On Expression" "selection" "any"
and the script contents are just:

selection = sizeof(getattribute(Menu, 'items')); (substitute whatever the name of your menu object is for Menu)
By adding these lines of code, it seems to have defeated the actual function of the choices in the menu (in this case, "File" options like new, open, close, etc., of which I have 5). I'm absolutely positive that it is my almost complete lack of understanding of how scripts are to be created that is problem.

In these two menus objects ("MenuFile" & "MenuEdit") I have a "Custom MIDI" script to allow for sending ascending controller numbers to Cubase to execute the intended command. For the Edit menu, clicking and pulling down to the first option, "undo", sends controller 0. Selecting "undo" should send controller 1, "delete" controller 2, etc. This worked properly before I added the new script objects and lines.

[img]http://www.octobersongs.com/files/lemur/projWindow2.png[/img]

[img]http://www.octobersongs.com/files/lemur/mapping2.png[/img]

This is how the adapted script now reads (in which I'm sure there are errant and unnecessary lines).

[img]http://www.octobersongs.com/files/lemur/script.png[/img]

Again oldgearguy, I appreciate your attention.

jc
You might have to be a bit more selective about when/where you reset the selection value. :D

If you have a script that does things based on the menu selection, I'd reset the selection value at the end of that script. That way, you act on the menu choice, do your stuff, then reset the selection value for the next time around. So, after you send out the MIDI info, add the reset of selection right at the end of that script and see what happens.

(don't forget to delete the "On Expression" script too)
Thank you softcore.

I adapted your "horizontal_menu" so that tapping the menu options would send the appropriate control change (118 - 125) and, even though each option works properly, I'm left with the original problem of not being able to reselect the same option, like if I were to repeatedly "paste" data. Your example functions in the same way my menu object does, having to choose another menu option before I can reselect the original option.

jc
Thanks again oldgearguy.

I'm afraid I just don't have the level of understanding to apply your instruction here to the existing "redu()" script. Was trying to conserve on space, but it might come down to your original observation of just having separate "buttons".

jc

oldgearguy wrote:You might have to be a bit more selective about when/where you reset the selection value. :D

If you have a script that does things based on the menu selection, I'd reset the selection value at the end of that script. That way, you act on the menu choice, do your stuff, then reset the selection value for the next time around. So, after you send out the MIDI info, add the reset of selection right at the end of that script and see what happens.

(don't forget to delete the "On Expression" script too)
I didn't see any attachments to your messages. Why not post the script in question? It's a straightforward matter to add that extra line to the script at the correct place and you should be done with this particular problem.

It's very hard to give advice out of context. I try to post the most bare-bones solution to make it easy for the OP to adapt it to their needs. Sometimes, more context is needed to post a better solution or to get the app up and running quicker.
oldgearguy wrote:I didn't see any attachments to your messages. Why not post the script in question? It's a straightforward matter to add that extra line to the script at the correct place and you should be done with this particular problem.

It's very hard to give advice out of context. I try to post the most bare-bones solution to make it easy for the OP to adapt it to their needs. Sometimes, more context is needed to post a better solution or to get the app up and running quicker.
oldgearguy,

Here are the links to the screenshots I'd posted before. Let me know if they're not visible.

This is how the adapted script (your script) now reads (in which I'm sure there are errant and unnecessary lines).
[img]http://www.octobersongs.com/files/lemur/script.png[/img]

Project window showing both Edit and File menus
[img]http://www.octobersongs.com/files/lemur/projWindow2.png[/img]

Mapping window for Edit menu
[img]http://www.octobersongs.com/files/lemur/mapping2.png[/img]

Lemur Design window - a rough of how it may look and function (Edit window open, File window closed)
[img]http://www.octobersongs.com/files/lemur/LemurDesignWindow.png[/img]

And while I'm at it, here's the actual lemur file attached below.

Let me know if I'm missing anything for context.

Thank you,

jc

Cubase.jzml.zip
I'll load it into the Lemur editor when I get home later today (don't have the editor around at my day job), but just looking at the raw jzml file I see where we have the disconnect. (and I think you did mention it earlier). You are using the custom MIDI messages to send MIDI CC's and other info as a base number+offset from the menu selection.

I typically do everything using scripts and don't use the custom MIDI messages; mainly because I came from a programming background and it's also easier to completely control what you send and when you send it.

So, adding the script bits I posted would indeed behave unexpectedly in your configuration. I'll see if there's a way to cleanly incorporate the idea into your structure.

BTW - no images show up for me, but again, that just may be the filters and firewalls that are between me and the outside world.
octobersongs wrote:Thank you softcore.

I adapted your "horizontal_menu" so that tapping the menu options would send the appropriate control change (118 - 125) and, even though each option works properly, I'm left with the original problem of not being able to reselect the same option, like if I were to repeatedly "paste" data. Your example functions in the same way my menu object does, having to choose another menu option before I can reselect the original option.

jc
Yes but what I meant to say, is that you can toy around programmatically however you want because now its not a closed "menu object"....

Here...I replaced the switches with pads and now the selection is ALWAYS triggered because it resets to a "null" selection (actually its menu items count so you just have to not map the "no tap" selection midiwise)

horizontal_menu-pads.jzml
attached is your basic app with some minor changes to MenuFile and MenuEdit.

I added a script and set the Target for Selection and for out to None (they were MIDI 1 in your original). Comparing the output of the original and the modified in MIDI-Ox, the outputs are the same in the same order.

If you want to compare and contrast, click on the script name in the editor, set the Execution to Manual, click on out and selection and set their targets back to MIDI 1 and re-run it.

Note that MenuEdit is sending control change messages to 2 different channels and MenuFile is sending both to the same channel. Not sure if that was intentional or not, but I left it as-is.

Tom

Cubase_script.zip
oldgearguy wrote:attached is your basic app with some minor changes to MenuFile and MenuEdit.

I added a script and set the Target for Selection and for out to None (they were MIDI 1 in your original). Comparing the output of the original and the modified in MIDI-Ox, the outputs are the same in the same order.

If you want to compare and contrast, click on the script name in the editor, set the Execution to Manual, click on out and selection and set their targets back to MIDI 1 and re-run it.

Note that MenuEdit is sending control change messages to 2 different channels and MenuFile is sending both to the same channel. Not sure if that was intentional or not, but I left it as-is.

Tom

Tom,

This works perfectly. Thank you very much. Applying it to a few other menus. I appreciate the attention.

jc
Softcore wrote:
octobersongs wrote:Thank you softcore.

I adapted your "horizontal_menu" so that tapping the menu options would send the appropriate control change (118 - 125) and, even though each option works properly, I'm left with the original problem of not being able to reselect the same option, like if I were to repeatedly "paste" data. Your example functions in the same way my menu object does, having to choose another menu option before I can reselect the original option.

jc
Yes but what I meant to say, is that you can toy around programmatically however you want because now its not a closed "menu object"....

Here...I replaced the switches with pads and now the selection is ALWAYS triggered because it resets to a "null" selection (actually its menu items count so you just have to not map the "no tap" selection midiwise)

Thanks Softcore. Working your idea into another interface. Thank you for the much needed help.

jc