GENERIC REMOTE: Why are so many commands modal?

[Aurasphere]

I understand there are of course many commands that should be active only on focused window types but
eg Expand inserst/sends etc?

Its common to tweak some of these with the project window open…seems mixer has to be focused for these to work; why?

And is there a trick to have the exclusive expand on the rack always move to the top of the called rack and not leave the top buried? Works on some and not on others ie ifx no, sends yes despite varying slot height/number?

Little things but its nice to have stuff working elegantly

[cubace]

It is very annoying. There should be a property of the command. It is very useful to use commands that are follow the window focus, but it also very useful with commands that does not need to follow window. One example is mixer controllers that use shift to add/remove channels from selection. You can not do add/remove without windows focus.
It should be clear what scope each function have.

[Aurasphere]

Just a nice object model map would be nice…like Live LOM
Actually the python remote scripting absolutely rocks!

[cubace]

python scripting environment would be very nice. Or java. Or C++ But I think python is a lot easier.

[oqion]

Lua would perform better. And the components are already there at Steinberg for Lua.

In my opinion, Python is very disappointing language. And I have written python almost every week for nearly a decade.

Quite frankly, Python is broken. It has always been broken, and as new features are added to fix it, it gets more broken. It is the worst thing that could have ever happened to the software community.

If you go to Maven to get some Java, it typically works, and does what it is suppose to do. There are unit tests, the community is supportive.

If you go to PyPi to get some Py, 9 times out of 10 it either doesn’t work or it performs so poorly, that it might as well not work. There are never unit tests and the community isn’t supportive, because they don’t know anything about what you are trying to use, because there are hundreds of other packages that claim to do exactly the same thing, and also do not work.

I could go on and on about just how horrible Python is. If you want to work with Steinberg family of products like HALion, then Lua is already established, and it is a very good, very simple language.

That said, Python would still be better than disparate XML files and PLE HEX.

[cubace]

Python is quick and dirty and seems to be very popular for teaching kids programming.
There are many programming languages to choice from. The best would of course be a API that can be used from many different languages. But I think we should be happy if we get anything that is real “programming”.

[Aurasphere]

I hear you. I was reporting that, as a paid programmer of scripting for 25 years…there is no perfect solution. Python was a big desilt for me…there were NO real docs for the remote script BUT in context of Live, once you ‘get’ it and in context of ie remote midi device scripting; there hasnt been much that you cant do…and Im doing pretty sophisticated gesturing etc that isnt in the marketplace yet.

In context to application re: Live…it rocks!

Im sure with your experience in Lua and my lack of it…there is probably more to learn re: perfect solutions…but right now…generic remote is a decent start but half baked unfortunately.
Bome has been the game changer for me and although its very basic and a bit frustrating for the deeper stuff…it has good support and keeps everything portable (ie its a masthead for all midi in the system) .

@oqion

disparate XML files

The xml has actually been great for me as its n excellent format for exchange and without it you cant use spreadsheets to manage control map overviews etc quite so easily.

Adding some finesse and complete what is already there…not a lot of work but a lot of gain.
More than that too is a language framework that facilitates the psychology easily ie right left /Tree.branch.leaf extensibility, in context is the greatest missing element in all of the daws, Im working on a left hand/right hand (left brain right brain) system atm and hope to make a youtube demo in about a month to show what I mean.

Anyway…for those interested in mapping with the painful dialog for GR…

Example is for 12 buttons (razer tartarus) with 4 gestures per key plus 2 modifiers (and 5 mode keys)…thats a total of 144 commands from 1 hand which sounds mad…but they forked like a tree so the psychology works so much better once trained and I have only just started populating the tree.
Add this to the MCU and its lightning compared to anything I have seen as yet…humbly said…Im sure there is something out there that is

Doing this without xml and instead using the GR editor…would create insanity hehe

Live/Python has a good LOM map…just that alone for GR would be so good.

[oqion]

Oh I wasn’t grousing about XML. It would just be nice if all of that XML, PLE, Macros/Key Commands, Generic Remote, if all of that were accessible as an API in Lua, or even sigh python.

I would much rather have XML than JSON. or anything else. In fact that PLEs aren’t actually XML is a big disappointment. When the saved data is in XML you can write your scripts to manage the static information in whatever language you like, as I am doing in Java because → JAXB.

Why is the body of the PLE in HEX? did they think that would speed it up? Seems like a last minute hack. (Sorry to whoever designed that!!! I’ve done similar things in the past.) But doing the hard work of making that all accessible so that we COULD access it through XML would be fine. I could live with that, as it is one more hard task I don’t have to do to reverse engineer the HEX.

I mean, the last thing they want is for the reved HEX to be out there doing god knows what. If it were any other app this would be a security breach because you can rev it by making one of everything. The thing is, it won’t take any longer to do that, than it did to write the Template I’m using right now, so it isn’t that much work really. Just getting that to proper XML would be amazing.

However, if it were in Lua, then you could manage things with variables in real time, you wouldn’t have to know ahead of time what the variables values were. In PLEs there are no variables. It’s copy and paste. And any compiled-to-XML solution can have variables, but you have to know what they might be ahead of time, because the code that runs is static. (Even if you do rev the HEX.)

In Lua you could have variables in real time, that you do not know the value of ahead of time.

I am intrigued by your spreadsheet to XML. for the gaming mouse. If you want to show it off, that would be a lot of fun. But that’s mapped to key commands right? not Generic Remote?

Have you seen this thread: Creative thinking needed (?), retrieve track names from Cubase to MIDI or OSC

grrrr: Java Script < Python

[Aurasphere]

@oqion

Why is the body of the PLE in HEX?

:-\ yeah why hehe

@oqion

I am intrigued by your spreadsheet to XML. for the gaming mouse. If you want to show it off, that would be a lot of fun. But that’s mapped to key commands right? not Generic Remote?

It creates the generic remote. There is then also an output to Bome that creates the midi translators from the keystrokes and that is the keystroke>midi>GR
if you know what I mean

The gaming keypad is composite with MCU the both are designed to work together along with raven type touchscreen…just about ready…but its mapping to the GR; yeah

Just roughing it up

The generic remote is linked to the MCU for feedback as well and the output goes to the training screen LCD at the bottom of the touch screen where it will be replaced with an interactive ‘extra buttons’ strip that is context sensitive with the shortcuts displayed

EDIT: You could use the akai fire as an alternative to Keypad but the keypad is super ergo/mini footprint and you dont have to lift your arm up etc

[oqion]

Nice!