MIDI Kinetics Forum

hi,

some years ago i created test routines for java apps and while creating a template on the lemur i remembered the function or classes from java.

is there such thng in the lemur scripting language?

i´m thinking about buliding a prophecy template, the idea would be to create functions for each parameter in a script of the root of the project.
every fader button would just call the function it needs to work.
this way, i believe, it would be easier to build such a large template, if i remember right the prophecy has a 1000+ parameters.


tricks and tipps and codesnippets more then welcome

cheers,
dbk

Unfortunately Lemur isn't exactly an Object Oriented Language, in its truest form its functional...

You can however work around this utilizing getexpression, setexpression, and getobject; so instead of neccessarily coding a class with methods, you build an object (Ie, store functions in a hidden container) and then call them from visible objects in the interface like a button or fader.

Also, keep this in mind as far as dynamic object references:

I've got 4 decks, DeckA, DeckB, DeckC, DeckD; all are indentical in structure but naturally they control different components in the software. Each Deck has 4 columns. I can use columnLinks to access any column of any deck by setting deckFocus. I can then run get and set expression functions on these columns:

Creating a script, naming it with a variable for example
functionF(a) and then setting it to execute "manual" isnt a similar thing to what we would call a java "function"?

I think the only difference is that you have to create your functions seperately....i.e. seperated scripts. These can indeed reside in a hidden container, named for example "functions", for ease of use and troubleshooting as noted by Traxus

More info on this: page 69 of Lemur manual.

thanks for the feedback

from what i remember (it´s been a while tho) a class with its function (or method, whatever you like to call it) would look something like this.

classname

function test
(
do something
)


function test2
(
do something
)

and so on ...

the i´d call it with test or test2 from wherever i want.


however, i found out, that the lemur can adress variables in a script. if i have a script with variable "f" i can reach it with scriptname.f and get no scripterrors.

anyway, i will test the suggestions you had for me.

thanks again,
dbk

The best workaround I've come up with for something along the lines of a class is to make hidden containers, full of highly abstracted functions...

So I have a Container called Globals, which is hidden (except when im editing it)

Within Globals I might have another container called Midi, and in Midi I might have an abstracted function which performs a complicated action that needs to be re used a lot in the layout.

Also, say I've got 3 identical virtual instruments in my software, and I'm controlling them in lemur. I could make one layout for one of them, map it, and then duplicate this entire layout for the other one in another page tab. However, this will eventually add up and make your template size huge. On the other hand, I could take a psuedo OOP approach, and seperate the faders/knobs etc from the hard values which could be stored in Globals.vstA Globals.vstB and Globals.vstC then setup a button to switch between controlling the 3 with just the one interface. The switch action would change which of the Globals.vstX was the parent for the interface, and thereby you would only have one instance of the actual interface, saving on template size and giving you a more fluid environment.

To remain this dynamic, you would have to use getexpression and setexpression to exchange the values between the parent containers and the proxy interface. Keep in mind that there can occsionaly be lag when using set/getepxression versus tying things to an absolute variable, but there are workarounds.

This all seems like a giant headache, but depending on the application can be entirely necessary. I have never peeped at the guts of LiveControl but I imagine they do something to this effect.

Hi
A couple of comments on this cross topic thread . . .
Yes you can declare functions in Lemur as mentioned by someone else, though I would note they have varying lexical and temporal scopes depending on where they are declared.
This should also have been the case with your 'test,test2' functions, which surely would have had scope relevant to the class they were declared in; or how they were declared i.e. global , private etc. …
In Lemur you can declared global functions at the root level of the project and access them any where. Beyond that the hierarchy is pretty much what is seen in the project pane.
If a function is in a container then the function becomes 'container.function()' when accessed outside its internal scope but as function() within its scope . . .

Re Object Oriented approaches . . . .
I see Lemur as providing a number of base classes that can be extended/subclassed/templatised in order to create new objects - and that these also have an object model that they also inherit from . . ..
The most fundamental of these are the UI objects which can be 'subclassed' i.e. created and saved as modules, then those subclassed objects used instead of inbuilt modules
For example - if you want a particular style of Fader with text value then modularise it and use the module rather then rebuilding every time you need one . . .
Another thing to consider is the use of supporting 'libraries' of functions (as mentioned by others) that can contain helper functions for various objects . . . .
It is possible to produce 'drop-in replacement' objects see http://forum.liine.net/viewtopic.php?f=34&t=2921
If the standard Lemur variables and functions are all appropriated exposed then interchange and reuse becomes simpler - though it does require the 'standards' for extension be followed . . .

Have also checked out a number of interesting possibilities that are suggested by combining all this into a more cohesive unit - sort of LemurX(tended) . . . .
With this would go further OO styled stuff in terms of extra OO libraries and some workarounds to do some other stuff . . .
Will do a bit more on all this again soon . ..