Lemur 5

Great update Lemurguys .

nick_liine wrote:One can no longer use the dot notation indirectly, by placing a dot after a variable that was set to point to an object.

Oh man, seriously? The new features (esp the canvas) look killer but this is absolutely crippling, dare I say a deal breaker, for anyone trying to take an OOP approach with any respectable degree of abstraction.

What if I've got a heavy template that would otherwise duplicate a large compound object. Rather than pull a copy/paste you can just build the interface with the display logic, and then build two (or more) hidden objects loaded with functions that control/track the heavy lifting so that all the faders and knobs and so forth only have to exist once.

So for instance, if you've got 2 or more decks in DJ software, and are listening to midi out on all of them, storing these values, and updating the display based on which deck is focused/displayed in the template, you could save a ton of template space by building the display interface once and storing the values and so forth elsewhere...

Previously this could be achieved by doing something like:

deckLinks[1] = DeckA;
deckLinks[2] = DeckB;
deckLinks[3] = DeckC;
deckLinks[4] = DeckD;

DeckA.deckValue = 1;
DeckB.deckValue = 2;
DeckC.deckValue = 3;
DeckD.deckValue = 4;

//now invalid
//m variable is from a MIDI_ARGS
//Column 1-4 objects are hidden containers that store values for visual feedback depending on which is focused upon

decl slot = m[0] - 22;
decl value =  m[1];
decl channel =  m[2];
decl deck = channel - 9;

decl deckObject = deckLinks[deck];
decl columnLink;
columnLink[1] = deckObject.Column1;
columnLink[2] = deckObject.Column2;
columnLink[3] = deckObject.Column3;
columnLink[4] = deckObject.Column4;

setexpression(columnLink[slot], 'filterState', value);

I've also utilized variables to store objects when the chain I need to access is too long (lemur seems to error out when an object chain is longer than 6 or 7 objects but not when you store part of that chain in a variable and then tag the rest on the end)...

What is the reasoning behind removing support for this syntax? The new canvas capabilities sound amazing but this is a pretty limiting trade off imo...

I don't appear to have any errors with old templates , I achieve what traxus refers to by having a working array to store the data for a single set of objects that have multiple uses . And transfer the required data from 'storage' arrays , as and when the single set of objects use changes. A very efficient method.

Well, my above example might not be the most complicated situation to work around (also one of the simpler I'm looking at, just for purposes of illustration). I've still got to explore whether some of the more complicated links can be re connected without turning my code into spaghetti or undergoing any major overhauls...

For instance, I'm pretty sure the following function would circumvent the issue (where d variable is the focused interface):

//-----getColumLinks(d);
decl columnLink;
if (d == 4) {
		columnLink[1] = DeckD.Column1;
		columnLink[2] = DeckD.Column2;
		columnLink[3] = DeckD.Column3;
		columnLink[4] = DeckD.Column4;
} else if (d == 3) {
		columnLink[1] = DeckC.Column1;
		columnLink[2] = DeckC.Column2;
		columnLink[3] = DeckC.Column3;
		columnLink[4] = DeckC.Column4;
} else if (d == 2) {
		columnLink[1] = DeckB.Column1;
		columnLink[2] = DeckB.Column2;
		columnLink[3] = DeckB.Column3;
		columnLink[4] = DeckB.Column4;
} else {
		columnLink[1] = DeckA.Column1;
		columnLink[2] = DeckA.Column2;
		columnLink[3] = DeckA.Column3;
		columnLink[4] = DeckA.Column4;
}

return columnLink;

Also, I'm still seeing some oddities in regards to object paths that are more than 5 nodes long. Previously, the following code was valid, but is no longer:

		decl t = MasterContainer.DeckObj.Content.Turntable.RemixControl;
		setexpression(t.BottomLeft.CaptureSource, 'source', value);

Altering to the following removes the yellow triangle error notifier, but the code in the script turns black rather than color coding correctly:

		decl t = MasterContainer.DeckObj.Content.Turntable.RemixControl.BottomLeft.CaptureSource;
		setexpression(t, 'source', value);

Traxus wrote:

nick_liine wrote:One can no longer use the dot notation indirectly, by placing a dot after a variable that was set to point to an object.

Oh man, seriously? The new features (esp the canvas) look killer but this is absolutely crippling, dare I say a deal breaker, for anyone trying to take an OOP approach with any respectable degree of abstraction.

What if I've got a heavy template that would otherwise duplicate a large compound object. Rather than pull a copy/paste you can just build the interface with the display logic, and then build two (or more) hidden objects loaded with functions that control/track the heavy lifting so that all the faders and knobs and so forth only have to exist once.

So for instance, if you've got 2 or more decks in DJ software, and are listening to midi out on all of them, storing these values, and updating the display based on which deck is focused/displayed in the template, you could save a ton of template space by building the display interface once and storing the values and so forth elsewhere...


I've also utilized variables to store objects when the chain I need to access is too long (lemur seems to error out when an object chain is longer than 6 or 7 objects but not when you store part of that chain in a variable and then tag the rest on the end)...

What is the reasoning behind removing support for this syntax? The new canvas capabilities sound amazing but this is a pretty limiting trade off imo...

I also ran into this (see my posts a page or two back) and with liberal use of findobject() and getexpression() you can pretty much keep your data structure intact and use very similar code to access the info. I personally hate very long if..then..else constructs, so I worked hard to avoid that kind of code duplication.

As far as variable size, I found that the Lemur editor seems to count the number of bytes in a variable you declare, not the number of bytes it takes up in storage.
This seems to apply only to when the variable is declared in an object and you attempt to fill in the value field directly.

So, if you did something like this: decl alphabet as a variable in a container and then tried to fill in the value field with {'a','b','c','d'}; that array is counted (IN THE EDITOR) as using up 17 bytes, since it seems to count the quotes and commas and braces. In fact, it's even worse since the editor 'pretty-prints' the array and adds a space after each comma so it counts as 20 bytes, not 4 as expected. You can easily test this by trying to type in a long array of single quoted characters. Once you get past a certain size (around 60 objects) it truncates the string when you click off the field. However, if you do this instead:

decl i;
for (i=0; i<25, i++)
myObject.alphabet = 0x61 + i;

you get an array of only 26 bytes and you can fill it up to 256.

whatisvalis wrote:With the update how do i now do the following?

MIDI_ARGS=display.value;

display is an expression

If 'display' is an expression, all you need to do is "MIDI_ARGS = display", expressions can not have child expressions.

sculptair wrote:Any word on whether Liine increased the 256 bit limitation? I've been trying to learn subtractive analog synth using analog604's Mophodashboard and my Mopho desktop, but have been handicapped by the inability of Lemur to load all of the parameters of a Mopho preset.

We have yet implemented a workaround the 256 array limit. It is on the wishlist.

newtfish wrote:Yes, I also am noticing that the new 5 editor shows 5% higher template size than 4 editor.

Why is this?

Is it not possible to remove the limit on the editor? Keep the template size monitor there to let us know where we are. But dont truncate our templates when loading them up, or stop us from adding objects once we reached the limit. Seems like a sledgehammer is being used to crack a nut here. If the lemur ipad app cant handle the size then I guess we can only blame ourselves then for going over the limit....

I cant say Ive had any problems with templates that are 100% filesize on the ipad app.

Max memory will go from 32MB to 48MB in 5.0.2

oldgearguy wrote: I also ran into this (see my posts a page or two back) and with liberal use of findobject() and getexpression() you can pretty much keep your data structure intact and use very similar code to access the info. I personally hate very long if..then..else constructs, so I worked hard to avoid that kind of code duplication.

Haven't messed with findobject yet, but it loos as though it takes a string of an objects node path as a paramater (rather than a raw object node path as per setexpression() or most other functions)?

Yup confirmed! It takes a string!

Traxus wrote:

oldgearguy wrote: I also ran into this (see my posts a page or two back) and with liberal use of findobject() and getexpression() you can pretty much keep your data structure intact and use very similar code to access the info. I personally hate very long if..then..else constructs, so I worked hard to avoid that kind of code duplication.

Haven't messed with findobject yet, but it loos as though it takes a string of an objects node path as a paramater (rather than a raw object node path as per setexpression() or most other functions)?

Right, but without re-quoting everything from earlier, if you pick the names appropriately, you can do things like findobject('container'+n) where n varies from 0 to whatever. So you get the variability in accessing/finding objects so that you can then use getexpression/setexpression and the combination gives you the same result as the old (unsupported/more direct notation) of:

decl ct = myContainer;
ct.knob2.x;

which no longer works.

Yet another Lemur 5 question - I hope this doesn't get lost...

I noticed when looking through and editing the .jzml file that the first object in a container no longer has a separate ID. Is this a change on purpose, or is it simply an oversight?

The reason for asking is that I thought the ID was how Lemur distinguished between the objects. If the change is purposeful, how can you track that object in the contianer, especially of the ordering changes using 'bring to front'/'send to back' ??

oldgearguy wrote:

Traxus wrote:

oldgearguy wrote: I also ran into this (see my posts a page or two back) and with liberal use of findobject() and getexpression() you can pretty much keep your data structure intact and use very similar code to access the info. I personally hate very long if..then..else constructs, so I worked hard to avoid that kind of code duplication.

Haven't messed with findobject yet, but it loos as though it takes a string of an objects node path as a paramater (rather than a raw object node path as per setexpression() or most other functions)?

Right, but without re-quoting everything from earlier, if you pick the names appropriately, you can do things like findobject('container'+n) where n varies from 0 to whatever. So you get the variability in accessing/finding objects so that you can then use getexpression/setexpression and the combination gives you the same result as the old (unsupported/more direct notation) of:

decl ct = myContainer;
ct.knob2.x;

which no longer works.

We are implementing an explicit findchild() function in 5.0.2 to reference objects in (nested) Containers.

Hey,

although a little late and unspecific,
I just want to compliment Liine to the latest update!

Sequencing objects! Triggered on clock
...waitin for that since JMdays.
And that new very flexible Canvas object...
Can´t wait to lay my hands on it

However, will wait till next update (bugfix), as I read about some trouble on Windows
(lol....this got a quite tradition on lemur software, äh? )
Hopefully @content for text will be fixed, need it hardly for Sequencomat.

Anyway - great update!
Thanks guys

g*mat