General
Lemur editor deleted whole template
Started by iPad_User on .
Sign in or create an account to join the conversation.
Hey out there,
I was working on my template, when my iPad started to show the template incorrect.
After I closed the editor and opened it again, 90% of what I did was deleted. And the rest seems also buggy. If I cope the rest into another template, save, close and open it again there is also a lot missing.
Whats going on here?!? I have to build the whole template again, which costs me hours of work....
I'm pretty disappointed.
I also tried to open the template on another system, but same there...it seems, that something damaged the file. Maybe it has something to do with the percentage in the right lower corner? The percentage was at 75% when it started to make confusing things. Now it's just 10%....
Chris
I was working on my template, when my iPad started to show the template incorrect.
After I closed the editor and opened it again, 90% of what I did was deleted. And the rest seems also buggy. If I cope the rest into another template, save, close and open it again there is also a lot missing.
Whats going on here?!? I have to build the whole template again, which costs me hours of work....
I'm pretty disappointed.
I also tried to open the template on another system, but same there...it seems, that something damaged the file. Maybe it has something to do with the percentage in the right lower corner? The percentage was at 75% when it started to make confusing things. Now it's just 10%....
Chris
Here is the problem:
I created a container with one tab. In this tab there is a channel strip with EQ, Compressor, Reverb, Solo, mute and Fader. If I duplicate this tab, than it begins to get confusing. The fourth tab is uncomplete and the other tabs are not on the display.... I dont know, whats going on here...
//edit: It seems that there are too much informations for the editor... sad!
See attachement. Thats what have to be copied...Maybe there are too much textobjects. But without them I have no idea, whats going on at the pots...
Foto_2.PNG
I created a container with one tab. In this tab there is a channel strip with EQ, Compressor, Reverb, Solo, mute and Fader. If I duplicate this tab, than it begins to get confusing. The fourth tab is uncomplete and the other tabs are not on the display.... I dont know, whats going on here...
//edit: It seems that there are too much informations for the editor... sad!
See attachement. Thats what have to be copied...Maybe there are too much textobjects. But without them I have no idea, whats going on at the pots...
Foto_2.PNG
I had a crash with the editor last night, and although I saved (ctrl s) every 5 minutes, most of what was done was lost after re-opening. Strangely, one object that was inserted at the end of the session was there, next to the other few objects that were still in the unarranged state. The editor allows you to work fast, so I guess there can happen some kind of overflow, and the file doesn't get properly written to disk when you enter the save command. Besides, at my place it crashes often on W7 64bit, but most of the time the layout was properly saved and it doesn't matter much. I just have to run the editor again and continue where I left off. But the crash yesterday was painful, I had lots of objects and labels that I have to recreate again. I will run the editor on the hackintosh from now on, so far it never crashed under Lion.
I've had the same problem. It's pretty much made lemur useless to me.
useless? Don't say that. I tried to continue my layout, and it does not save. Even under a different name. I'm at 11%, is this the limit for one layout? If so, I can live with it, although I wanted to put all my VSTi layouts into one big multipage, plus one big (about 10%) layout for the DAW. I expected to make one layout including everything with 60-70%. 
EDIT: after a few tests it appears that the memory limit around 11% is true. When I delete Elements and the memory indicator goes down to 1%, the editor can save new elements as normal. I admit this is a bit disappointing. Still a brilliant software, but limited to a few kilobytes? I still can't believe it. Maybe with importing modules one can overcome this limitation.
EDIT: no, it doesn't work. When I import a bunch of modules and go up to 17%, I can save, but when I re-open, some elements are missing, and the indicator shows . . . 11%. I hope this is just a temporary limitation. True, loading layouts is fast, but not as fast as a tab.
EDIT: after a few tests it appears that the memory limit around 11% is true. When I delete Elements and the memory indicator goes down to 1%, the editor can save new elements as normal. I admit this is a bit disappointing. Still a brilliant software, but limited to a few kilobytes? I still can't believe it. Maybe with importing modules one can overcome this limitation.
EDIT: no, it doesn't work. When I import a bunch of modules and go up to 17%, I can save, but when I re-open, some elements are missing, and the indicator shows . . . 11%. I hope this is just a temporary limitation. True, loading layouts is fast, but not as fast as a tab.
Guys there is a bug in the editor 3.0.2 that will not save a template larger than 512K. So check your files as you work and save as new versions all the time.
If you open a saved .JZML file in a text editor, it should have </JZML> as the last XML tag. If not, it is corrupted.
You can edit much larger than 512, but saving will corrupt.
The way that I am getting around this is exporting object trees and then re-importing.. it is a big pain because I have well over 1.5Meg of code that needs to talk to other interface objects to have any purpose.
Also even though you can edit a big Template in editor and send to iPad Lemur, the iPad s/w gets confused with too many objects, so interface tabs will go missing.. and objects will disappear there.
I'm looking forward to the fixes for these very much. I can't test my Template application at this point because one of 4 interface containers is now over 512K, and it needs two other interface containers to even run.
Other than that, I love the possibilities of Lemur...
If you open a saved .JZML file in a text editor, it should have </JZML> as the last XML tag. If not, it is corrupted.
You can edit much larger than 512, but saving will corrupt.
The way that I am getting around this is exporting object trees and then re-importing.. it is a big pain because I have well over 1.5Meg of code that needs to talk to other interface objects to have any purpose.
Also even though you can edit a big Template in editor and send to iPad Lemur, the iPad s/w gets confused with too many objects, so interface tabs will go missing.. and objects will disappear there.
I'm looking forward to the fixes for these very much. I can't test my Template application at this point because one of 4 interface containers is now over 512K, and it needs two other interface containers to even run.
Other than that, I love the possibilities of Lemur...
hey analog, thank you for this info. I also observed that it is 512 kB and not above, so I'm constantly monitoring the value as I'm circling around 486 kB. As I said above, I can live with it, I just need to know where the boundaries are. If next week a new editor version allows saving 5 MB, I would have a fair bit of restructuring to do.
I´m suffering this issue also. Hoping that a new editor version fixes it, because now my project is stopped because of this.
BTW- Your interface looks tight, like for a proper old school mastering EQ..good job!
iPad_User wrote:Here is the problem:
I created a container with one tab. In this tab there is a channel strip with EQ, Compressor, Reverb, Solo, mute and Fader. If I duplicate this tab, than it begins to get confusing. The fourth tab is uncomplete and the other tabs are not on the display.... I dont know, whats going on here...
//edit: It seems that there are too much informations for the editor... sad!
See attachement. Thats what have to be copied...Maybe there are too much textobjects. But without them I have no idea, whats going on at the pots...
Thanks!
This is a preset I built for live mixing via Brainspawn Forte. I will use the Waves SSL EQ, but because of space, I decided not to integrate the q-factor pot.
Well, let's hope, that this will be fixed soon, so we can go on. Of course I will share my template as soon as it is ready...
This is a preset I built for live mixing via Brainspawn Forte. I will use the Waves SSL EQ, but because of space, I decided not to integrate the q-factor pot.
Well, let's hope, that this will be fixed soon, so we can go on. Of course I will share my template as soon as it is ready...
Hi
Just thought I would mention that the iPad implementation is currently not that different to the Legacy Lemur . . .
ie - if you can't do it on a Legacy , you can't do it on the iPad - And people have used the Lemur successfully for years . . .
The Molamur project takes up over 95% Legacy Lemur capacity, yet less than 15% on iPad - so 60% iPad use is 4 to 5 times that of the original . . .
Lots of famous International artists have managed to successfully 'get by' with pretty much the same capabilities that are now called 'limits' . . .
Sometimes it is a simple fact that something can only do 'so much' and we simply have to work within those limitations . . .
I realise this is somewhat of an 'old-school' approach but that's just the way it is - you can't always get what you want . . .
Or , worse still in the modern vernacular, you may have to 'work at it and solve the problem yourself' - and it may not be easy
I can make larger projects than the editor allows but than other technical issue arise involving even more work . . .
Yes I could 'hack away' and come up with a 1M project but it would involve more work than I wish to invest, so I don't - I am prepared to await Liine's fix . . .
So I think it is a case of working within the Lemur limitations - what ever they may be - and awaiting improvements . . .
Cheers
MM
Just thought I would mention that the iPad implementation is currently not that different to the Legacy Lemur . . .
ie - if you can't do it on a Legacy , you can't do it on the iPad - And people have used the Lemur successfully for years . . .
The Molamur project takes up over 95% Legacy Lemur capacity, yet less than 15% on iPad - so 60% iPad use is 4 to 5 times that of the original . . .
Lots of famous International artists have managed to successfully 'get by' with pretty much the same capabilities that are now called 'limits' . . .
Sometimes it is a simple fact that something can only do 'so much' and we simply have to work within those limitations . . .
I realise this is somewhat of an 'old-school' approach but that's just the way it is - you can't always get what you want . . .
Or , worse still in the modern vernacular, you may have to 'work at it and solve the problem yourself' - and it may not be easy
I can make larger projects than the editor allows but than other technical issue arise involving even more work . . .
Yes I could 'hack away' and come up with a 1M project but it would involve more work than I wish to invest, so I don't - I am prepared to await Liine's fix . . .
So I think it is a case of working within the Lemur limitations - what ever they may be - and awaiting improvements . . .
Cheers
MM
I agree. Limitations are good for creativity; too many options can make a choice difficult.
I now make one interface for one VSTi, and load it everytime I need it. I'm thinking about doing the 'selected DAW channel' with touchOSC. On the iPad, I could switch between touchOSC andLemur.
I now make one interface for one VSTi, and load it everytime I need it. I'm thinking about doing the 'selected DAW channel' with touchOSC. On the iPad, I could switch between touchOSC andLemur.
But: Why do they implemented this "percentage-cake"? If it goes over 11%, it gets damaged. That is irritating.
And: For me it is not an argument to say, that the legacy worked like this for years. Time goes on and the iPad is really powerful. 512kB is really nothing today and I'm sure, that the iPad can handle much more. As you say: It is 4 or 5 times the legacy. That should be an improvement and not a limitation.
So, I really hope, to get a fix soon.
Of course I can create a new map for every channel, but for live mixing it sucks! I need permanent access to every channel (EQ, FX, Fader) and this should be possible in a fast way. Live I don't have the time to look for the right presetmap and get confused by 16 different maps
And: For me it is not an argument to say, that the legacy worked like this for years. Time goes on and the iPad is really powerful. 512kB is really nothing today and I'm sure, that the iPad can handle much more. As you say: It is 4 or 5 times the legacy. That should be an improvement and not a limitation.
So, I really hope, to get a fix soon.
Of course I can create a new map for every channel, but for live mixing it sucks! I need permanent access to every channel (EQ, FX, Fader) and this should be possible in a fast way. Live I don't have the time to look for the right presetmap and get confused by 16 different maps
Hi
'Percentage-cake' is simply the same as it was with the original Lemur's Jazz Editor . . .
The argument is simply that many people have achieved complex things within that 512k limitation. You just need to be efficient.
Yes, technology progresses and eventually this issue will be addressed, but I don't see it as the 'show-stopper' that some think it is . . .
Re : specifics of your mixing desk - permanent access does not necessarily mean everything duplicated multiple times . . .
Permanent and fast access often comes down to interface/program design, efficient use/re-use of objects/code etc . . .
Looking at your pics (really doesn't help much - actual templates is better) I can see what I would call 'issue' . . .
There appears to be lots of duplication that may not be needed and is bloating your project . . .
It appears you have 16 tabs of identical layouts, possibly all with duplicated local code on each page, yet only one page is visible at a time . . .
It may be that central scripting could free up space - if functionality is duplicated in multiple objects scripts it is better to make them callable functions . .
Another approach would be to have only one interface page that can be selectively assigned to any channel via a selector of some sort . . .
One press could switch you to any channel - instead of multiple tabbing needed in your design . . . .
Or 16 faders on one page - controlling vols is a most common action when live mixing - and a button on each that shows/hides an eq or fx container for that channel as needed.
To me, an overly-large and inefficient 1M patch is not an improvement over the 512k limit . . .
Maybe post some of your patch and you may get some better feedback on how to improve you design and coding . . .
No doubt this limit will get raised in the next update - which will probably be fairly soon
Currently you can however edit the jzml file by hand to make HUGE patches but it's not for the faint-hearted . . .
Cheers
MM
'Percentage-cake' is simply the same as it was with the original Lemur's Jazz Editor . . .
The argument is simply that many people have achieved complex things within that 512k limitation. You just need to be efficient.
Yes, technology progresses and eventually this issue will be addressed, but I don't see it as the 'show-stopper' that some think it is . . .
Re : specifics of your mixing desk - permanent access does not necessarily mean everything duplicated multiple times . . .
Permanent and fast access often comes down to interface/program design, efficient use/re-use of objects/code etc . . .
Looking at your pics (really doesn't help much - actual templates is better) I can see what I would call 'issue' . . .
There appears to be lots of duplication that may not be needed and is bloating your project . . .
It appears you have 16 tabs of identical layouts, possibly all with duplicated local code on each page, yet only one page is visible at a time . . .
It may be that central scripting could free up space - if functionality is duplicated in multiple objects scripts it is better to make them callable functions . .
Another approach would be to have only one interface page that can be selectively assigned to any channel via a selector of some sort . . .
One press could switch you to any channel - instead of multiple tabbing needed in your design . . . .
Or 16 faders on one page - controlling vols is a most common action when live mixing - and a button on each that shows/hides an eq or fx container for that channel as needed.
To me, an overly-large and inefficient 1M patch is not an improvement over the 512k limit . . .
Maybe post some of your patch and you may get some better feedback on how to improve you design and coding . . .
No doubt this limit will get raised in the next update - which will probably be fairly soon
Currently you can however edit the jzml file by hand to make HUGE patches but it's not for the faint-hearted . . .
Cheers
MM
hey,
thanks for your answer.
Yes, you are right. I duplicated the tabs. And you are also right, that it would be easier, to "recall" the actual status by pressing a button.
But I'm not familiar with scripting and for me the scripts which are described in the manual, are not enough, to solve my problems. And because I don't want to ask the forum for every script I need, I just duplicate.
See attachement for template.
Would you be so kind and tell me, how to script a button, to work like you explained (recall)?
Thank you very much.
Chris
new.jzml.zip
thanks for your answer.
Yes, you are right. I duplicated the tabs. And you are also right, that it would be easier, to "recall" the actual status by pressing a button.
But I'm not familiar with scripting and for me the scripts which are described in the manual, are not enough, to solve my problems. And because I don't want to ask the forum for every script I need, I just duplicate.
See attachement for template.
Would you be so kind and tell me, how to script a button, to work like you explained (recall)?
Thank you very much.
Chris
new.jzml.zip
I now found this:
http://liine.net/forum/viewtopic.php?f=25&t=581&start=10
Thats pretty interesting. But it seems complicated. Maybe I can build up my template on this one...
http://liine.net/forum/viewtopic.php?f=25&t=581&start=10
Thats pretty interesting. But it seems complicated. Maybe I can build up my template on this one...
Yep
Definitely some good stuff there must have missed the end of that thread . ..
You could certainly extend/adapt /meld that code with 8 faders into something
I would recommend going through many/all of the available projects and tutes . . .
Have at look at what can be done already and the ways people deal with problems
There is lots of good learning material in the library though not all is well documented.
There are lots of different approaches available that you may not be aware of yet
A lot of it may seem complex but it gets easier - it is like learning a language, in fact it is . .
It is also learning as well as inventing an instrument and controller that is virtual and changeable
Have a look at how mixers have changed over the years - multifunctionknobs, new layouts etc . . .
Thinking in this way will reveal different solutions to mimicking older style hardware approaches
Had a quick look at your project but am guessing it may change from here on
Cheers
MM
Perhaps we should start a new thread to deal with this rather than continuing here . . .
Definitely some good stuff there must have missed the end of that thread . ..
You could certainly extend/adapt /meld that code with 8 faders into something
I would recommend going through many/all of the available projects and tutes . . .
Have at look at what can be done already and the ways people deal with problems
There is lots of good learning material in the library though not all is well documented.
There are lots of different approaches available that you may not be aware of yet
A lot of it may seem complex but it gets easier - it is like learning a language, in fact it is . .
It is also learning as well as inventing an instrument and controller that is virtual and changeable
Have a look at how mixers have changed over the years - multifunctionknobs, new layouts etc . . .
Thinking in this way will reveal different solutions to mimicking older style hardware approaches
Had a quick look at your project but am guessing it may change from here on
Cheers
MM
Perhaps we should start a new thread to deal with this rather than continuing here . . .
Hi Macciza,
I have admired and learned from the code you have posted in other threads, thanks!
I expect that the iPad version will take the Lemur idea above and beyond that of the old hardware,
but if it cannot grow to the full power of the iPad or be stable in operation then some other app on the market will (sorry but that is simply how markets work).
And if that app goes leaps ahead of where Lemur already has the advantage then iPad Lemur will be obsoleted like the Jazzmutant
hardware was by the inexpensive iPad innovation.
I see this first year as a critical time for the new incarnation of Lemur, if we don't make a good variety of templates available then the software will not be able to justify the price or sell much at all.
For me, it is a labor of love and obsession.
I don't mind working under limitations so long as they are reasonable limitations.
1980s DOS memory sized limitations are not reasonable to me on a general purpose computer like iPad (although 512K would be awesome for a programmable interface controller or other embedded microcontroller) : ))
The overall awesomeness of Lemur has made me actively code for the first time in over 12 years. I have been programming the Lemur hours every day for the past 3 weeks. I go to bed at night thinking about how to solve or design the next area of design in Lemur.
: )
I have admired and learned from the code you have posted in other threads, thanks!
I expect that the iPad version will take the Lemur idea above and beyond that of the old hardware,
but if it cannot grow to the full power of the iPad or be stable in operation then some other app on the market will (sorry but that is simply how markets work).
And if that app goes leaps ahead of where Lemur already has the advantage then iPad Lemur will be obsoleted like the Jazzmutant
hardware was by the inexpensive iPad innovation.
I see this first year as a critical time for the new incarnation of Lemur, if we don't make a good variety of templates available then the software will not be able to justify the price or sell much at all.
For me, it is a labor of love and obsession.
I don't mind working under limitations so long as they are reasonable limitations.
1980s DOS memory sized limitations are not reasonable to me on a general purpose computer like iPad (although 512K would be awesome for a programmable interface controller or other embedded microcontroller) : ))
The overall awesomeness of Lemur has made me actively code for the first time in over 12 years. I have been programming the Lemur hours every day for the past 3 weeks. I go to bed at night thinking about how to solve or design the next area of design in Lemur.
: )
M acciza wrote:Hi
Just thought I would mention that the iPad implementation is currently not that different to the Legacy Lemur . . .
ie - if you can't do it on a Legacy , you can't do it on the iPad - And people have used the Lemur successfully for years . . .
The Molamur project takes up over 95% Legacy Lemur capacity, yet less than 15% on iPad - so 60% iPad use is 4 to 5 times that of the original . . .
Lots of famous International artists have managed to successfully 'get by' with pretty much the same capabilities that are now called 'limits' . . .
Sometimes it is a simple fact that something can only do 'so much' and we simply have to work within those limitations . . .
I realise this is somewhat of an 'old-school' approach but that's just the way it is - you can't always get what you want . . .
Or , worse still in the modern vernacular, you may have to 'work at it and solve the problem yourself' - and it may not be easy
I can make larger projects than the editor allows but than other technical issue arise involving even more work . . .
Yes I could 'hack away' and come up with a 1M project but it would involve more work than I wish to invest, so I don't - I am prepared to await Liine's fix . . .
So I think it is a case of working within the Lemur limitations - what ever they may be - and awaiting improvements . . .
Cheers
MM
mbncp's jzml has a solid example of using indexes to load arrays and
how to processing the midi in CCs to load values. Good stuff, I missed or forgot about that thread, so thanks for pointing it out.
The application is more complicated than duplicating tabs, but will save a good chunk of memory...
and cpu as the Lemur doesn't need to reconsider all of those objects on each of its frames.
Also note that he renames stuff like variables to shorter names, this is something that I learned too.
All the long variable names become unwieldy and meaningless.
so "Container" might become "cTabTop" and some things are fine to keep meaningless like text names we'll never reference.. "Text1" so becomes "t1"
I ran into the similar prob of duplicating basically the same interface controls for 8 top level "slots" as tabs ("1-8").
Each slot contains a tabbed container with 4 tabs (named "Source","Modifier Source", "Timing+Delay", "Output" and each of those has another tabbed container of sub-options
with up to 8 options (under "Source" it is "Multiball","MIDI IN","Mixer Dashboard","Variables","Other slot","System LFO","Accelerometer","Note Generator").
So duplicating this out would have resulted in 256 container objects (32 per slot).
When a single slot tab's worth of controls and code took up more than 300K, I knew that duplicating it would
not work so well.
So I created next/last page buttons to switch between slots.
Still working on the code to load current values into the sliders/knobs when the pages are turned.
But when items are selected using interface, the slider or menu or knob changes a value of the current page's index for that control,
and an indicator at the top of the screen is changed to slot number. Checkout Antonio's excellent code in his
latest template:
http://liine.net/forum/viewtopic.php?f=26&t=901
Now I'm still out of usable space so it's not done.. but I know how to finish it once the bugs and memory/filesize restrictions are lifted. Either that or I break it apart and use less options.
In any case, cheers!
-J
how to processing the midi in CCs to load values. Good stuff, I missed or forgot about that thread, so thanks for pointing it out.
The application is more complicated than duplicating tabs, but will save a good chunk of memory...
and cpu as the Lemur doesn't need to reconsider all of those objects on each of its frames.
Also note that he renames stuff like variables to shorter names, this is something that I learned too.
All the long variable names become unwieldy and meaningless.
so "Container" might become "cTabTop" and some things are fine to keep meaningless like text names we'll never reference.. "Text1" so becomes "t1"
I ran into the similar prob of duplicating basically the same interface controls for 8 top level "slots" as tabs ("1-8").
Each slot contains a tabbed container with 4 tabs (named "Source","Modifier Source", "Timing+Delay", "Output" and each of those has another tabbed container of sub-options
with up to 8 options (under "Source" it is "Multiball","MIDI IN","Mixer Dashboard","Variables","Other slot","System LFO","Accelerometer","Note Generator").
So duplicating this out would have resulted in 256 container objects (32 per slot).
When a single slot tab's worth of controls and code took up more than 300K, I knew that duplicating it would
not work so well.
So I created next/last page buttons to switch between slots.
Still working on the code to load current values into the sliders/knobs when the pages are turned.
But when items are selected using interface, the slider or menu or knob changes a value of the current page's index for that control,
and an indicator at the top of the screen is changed to slot number. Checkout Antonio's excellent code in his
latest template:
http://liine.net/forum/viewtopic.php?f=26&t=901
Now I'm still out of usable space so it's not done.. but I know how to finish it once the bugs and memory/filesize restrictions are lifted. Either that or I break it apart and use less options.
In any case, cheers!
-J
iPad_User wrote:I now found this:
http://liine.net/forum/viewtopic.php?f=25&t=581&start=10
Thats pretty interesting. But it seems complicated. Maybe I can build up my template on this one...
Hi
I am certainly not arguing for the limits to be maintained - and I expect that soon they will be gone . . .
I see the current situation as a case of 'Argue for your limitations and they will be yours' -
Meaning that it is only when you let limits stop you that they are actual limits - redefining/redesigning your solution within the limits removes them . .
I realise this is really just a matter of perspective and perhaps a bit etheral and so I find it is hard to explain via webforum messages . . .
That is why I cite the marvellous complex projects that have been done with the limits of the original Lemur as examples of what has been done before . .
I certainly want Leemur to push the envelope of what is possible on the iPad platform
And we should remember the app has only been out on iPad a little over a month now . . .
I am hoping to see a number of early issues resolved soon in the first app update . . .
Enjoyable discussion and lots of future ground to discuss related to this as well
Might start another thread with a better title and let this one fall down the list . . .
Cheers
MM
I am certainly not arguing for the limits to be maintained - and I expect that soon they will be gone . . .
I see the current situation as a case of 'Argue for your limitations and they will be yours' -
Meaning that it is only when you let limits stop you that they are actual limits - redefining/redesigning your solution within the limits removes them . .
I realise this is really just a matter of perspective and perhaps a bit etheral and so I find it is hard to explain via webforum messages . . .
That is why I cite the marvellous complex projects that have been done with the limits of the original Lemur as examples of what has been done before . .
I certainly want Leemur to push the envelope of what is possible on the iPad platform
And we should remember the app has only been out on iPad a little over a month now . . .
I am hoping to see a number of early issues resolved soon in the first app update . . .
Enjoyable discussion and lots of future ground to discuss related to this as well
Might start another thread with a better title and let this one fall down the list . . .
Cheers
MM