MIDI Kinetics Forum

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

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.

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

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

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

I now found this:
http://liine.net/forum/viewtopic.php?f= ... 1&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 . . .

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.
: )

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

iPad_User wrote:I now found this:
http://liine.net/forum/viewtopic.php?f= ... 1&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