MIDI Kinetics Forum

Are you using the latest versions?
I believe the issue is fixed, I can no longer reproduce it, it works fine either way Editor and App v 5.0.3 . . .
I can't recall now whether I saw the changing values before or just the float/int variance

My previous solution had been to write the value to an empty expr with an onLoad script
The use of floor() in any script/expression using that value addresses the errant float issue
It is akin to doing implicit casts to ensure that you never get a float instead of an int

Thanks for the reply. I have tried the latest version 5.0.3 app and editor. Alas it's still broken.

I'm interested in your technique of using an empty expression. Could you please modify MrBit's simple example project to demonstrate how to achieve it.

All that is needed is for the stored values to still be the same value after a project reload.

So to be clear;
Load "storeTest.jzml"
Allow the init script to run (i.e. set to OnFrame) that should set the monitor to be {536870915,47457457 } which is the values I want.
Set the init script back to OnExpression
Save the project
Quit the Lemur
Reload the project
Monitor now displays {536870880.000, 47457456.000}

obviously I can perform a floor on the monitor values at load. But that still gives me the wrong integer value, i.e.
{536870880, 47457456} != {536870915,47457457 }

Which is not what I stored. This seems pretty fundamental to me.

Cheers for help.

Ok
It is still a bit weird - earlier example file still acts weird

But I have a project built from scratch saving your numbers fine . . .??
Can also generate a rand()*0x7fffffff number stored to a var and have it recall??

What devices are you on? Have you sent a report to support ?
I think I may have already raise fit or a related issue.
Really not sure whats going on here . . .

threeLeggedLemur wrote: So to be clear;
Load "storeTest.jzml"
Allow the init script to run (i.e. set to OnFrame) that should set the monitor to be {536870915,47457457 } which is the values I want.
Set the init script back to OnExpression
Save the project
Quit the Lemur
Reload the project
Monitor now displays {536870880.000, 47457456.000}

One thing to check to help see where it is breaking -- After you set the init script back to OnExpression and save, open the .jzml file and see if the numbers are still OK there.

The reason I say that is because the version of storeTest.jzml that is attached in an earlier message already has the numbers truncated.

The .jzml files are basically XML files, so anything editor can open them. Doing a step, hitting save, then checking the .jzml may help determine if the problem is conversion on save or on reload, which may help the Liine guys to track down the issue.

Hi Guys,

Thanks oldgearguy. The plot thickens.

I've checked the file contents before saving the project and the file contains the correct values. So it must be the file loading that is causing the corruption.

In the original storeTest.jzml that MrBit posted. If you open the file in a text editor you can clearly see that the numbers are indeed correct and not truncated. However when the lemur loads the file the values get corrupted from that point on.

MrBit's original file has this;

<VARIABLE name="test=" value="536870915,47457457" send="1" osc_target="0" osc_trigger="1" osc_message="/test" midi_target="-1" midi_trigger="1" midi_message="0x90,0x90,0,0" midi_scale="0,16383" kbmouse_target="-1" kbmouse_trigger="1" kbmouse_message="0,0,0" kbmouse_scale="0,1,0,1"/>

After loading into the lemur and doing a save.

It's now corrupt and contains this;

<VARIABLE name="test=" value="536870880.000000,47457456.000000" send="1" osc_target="0" osc_trigger="1" osc_message="/test" midi_target="-1" midi_trigger="1" midi_message="0x90,0x90,0,0" midi_scale="0,16383" kbmouse_target="-1" kbmouse_trigger="1" kbmouse_message="0,0,0" kbmouse_scale="0,1,0,1"/>

@ Macciza, "But I have a project built from scratch saving your numbers fine . . .??
Can also generate a rand()*0x7fffffff number stored to a var and have it recall??"

Could you please supply your project which you have working? I would like to see how you achieved it as I'm not getting anywhere.

I have not yet reported the bug to Liine Support.

Cheers

Hey Macciza,

Any word on your working example project?

It's very frustrating to hear someone has a working project and wont seem to share.
It implies it is not a bug in the Lemur but rather a problem with my project. It doesn't seem worth contacting Liine if there is something I am doing wrong.

Thanks

Hi
Sorry - sometimes the exp dev stuff is all over the place . .

Have at look at this & see if works/makes any sense . .
Just your vale stored in different ways plus the rand() thing

Hi Macciza,

Thanks for the reply and project. I've had a look through it and noticed your setvar function is exectued on load.

That in effect just overwrites the corrupted values with the known example constants and hides the problem. I can't do this as the values are dynamically created by the user.

If you set your setvar function to execute OnExpression. Then save your project then reload. The values in var are corrupt.

I've attached your modified project project to illustrate the problem.

Thanks again for the help.

Yeah ok
Though I don't think having the script set execute on an empty expression is a particularly good example
Again I could get it to work with a Pad executing it , for a while then things go weird again
Same thing when setting var to zero rather then leaving unassigned
As I think I said before I think this is part of an issue that Liine are looking at for next release
I think it may be some sort of errant memory leak mucking things up
This is something that Liine will need to follow up on

Without knowing what you are wanting to do in all this apart from store and retrieve some large numbers not sure what else I can offer
I have not run any test on storing and retrieval of smaller numbers so not sure if altering your data approach will offer any hope
What are the numbers being used for anyway?

Hi,

I've been experimenting with the new canvas stuff. Thought I'd have a play with writing my own bitmap handling routines with a transparency mask.

I can fudge the issue by only using 24 bits of the available 32 but it's not very elegant and shouldn't be necessary. To be honest I was so surprised that such a fundamental problem could exist I just assumed I was doing something wrong.

I think I will dump the project until Liine fix the bugs as I cant keep wasting time fighting it.

Thanks again for trying to help.