Axe for Lemur ready for beta testers

Look for the little circle that shows percent memory used. You'll see the current setup is at 97% memory used.

If we had a template that removed the controllers and looper, we'd probably have enough to add what you're talking about. We can have multiple templates because users can modify and post their templates. That means users will need to update their templates when new firmware (and thus new scrutinizer template) comes out.

For example, I took the latest template and put the amps I use most in upper case on the amp select window.

Im little confused with your response Solo, Are you saying that there isnt enough Memory within the template to be able to add the 'Tone Match' section?
 
Im little confused with your response Solo, Are you saying that there isnt enough Memory within the template to be able to add the 'Tone Match' section?
Scrunitizer can confirm, but it's likely there isn't enough memory. Looks like programmers didn't add more memory to the Lemur app when they went to version 4. Doesn't make sense, mobile devices should have more than enough memory to run larger templates.

That said, I think the template can be modified to make room for your request, Scrutinizer can also confirm this.
 
Scrunitizer can confirm, but it's likely there isn't enough memory. Looks like programmers didn't add more memory to the Lemur app when they went to version 4. Doesn't make sense, mobile devices should have more than enough memory to run larger templates.

That said, I think the template can be modified to make room for your request, Scrutinizer can also confirm this.

Cheers dude, I await Scrutinizer's response, but its just something, for my bass patches i could REALLY do with lol

Seems little backwards to have a program on a item with the ability to do so much but then limit it to a small amount of memory :/

Cheers again!
 
Damn, had a nice detailed response typed up somehow it went poof and was gone.

Short answer:
Lemur memory is limited to 32MB
Lemur objects take lots of memory. Faders and knobs take >12kB each. A text object takes >3kB. Switches and pads objects take >20k.

I am working on a new version, which uses less memory using a control muxing technique (see the reverb block in 1.99b9). It is down to 90%, but I am adding a page w/ vocoder and enhancer controls, so it should be 92% or 93% when I release the next version.

The new version also has reworked low level code that mostly eliminates the possibility of unwanted parameter changes when opening dialogs. Last but not least, there is a new auto-sync feature.
 
Did you manage to make the dlgGeneral to work as supposed? The sizeof(swType.x) gets updated only if you press a switch. So if you had previously opened let's say the mic selection in the cab tab, than if you open the cab selection, the sizeof(swType.x) will be 11 instead of 130. This makes that the actual cab is not highlighted if it is above 10.
I spent a few days on this and couldn't get it done.
 
Did you manage to make the dlgGeneral to work as supposed? The sizeof(swType.x) gets updated only if you press a switch. So if you had previously opened let's say the mic selection in the cab tab, than if you open the cab selection, the sizeof(swType.x) will be 11 instead of 130. This makes that the actual cab is not highlighted if it is above 10.
I spent a few days on this and couldn't get it done.
Yes, I fixed that. The trick was to change the sequence of actions that occur as the generic dialog is made visible.
 
That trick didn't work for me, I am curious how do you exactly made the sequence of the actions.
I used another count-down timer to delay execution of the code that was in dlgGeneric.setType(). Seems that Lemur needs at least one full frame before it is safe to access the resized switch array.
 
No chance you could port the template over to TouchOSC, is there? It's one tenth of the cost...
IT appears Lemur is way more advanced, but do we really need that for controlling the Axe? I won't be using it live anyway... Well... Only in emergencies.
 
No chance you could port the template over to TouchOSC, is there? It's one tenth of the cost...
IT appears Lemur is way more advanced, but do we really need that for controlling the Axe? I won't be using it live anyway... Well... Only in emergencies.
Nope, it can't be done. Last time I checked, TouchOSC requires an OSC-to-MIDI translation somewhere in the data path and has other limitations.
 
Here it is.
https://dl.dropbox.com/u/54889552/AxeForLemur.2.00.zip

Change Log:
****************************************
Jan 18, 2013
Axe for Lemur version 2.00

Added Blocks:
- Enhancer
- Vocoder
- Crossover
- Tone Match

New Auto Sync feature:
- There are two ways to enable or disable the new feature:
--- Tap-hold the GetAll button
--- Go to Preset page, tap the AutoSync button
- Auto Sync queries the params of currently displayed block(s) after timed pause
- Switch to a different page in the template, and the controls update automatically
- The timed pause prevents midi flood if user is scrolling thru presets
- Changing presets in the template, mfc, or AxeII front panel triggers resync after timed pause
- There are some situations that can confuse the template, but you can still tap-hold any of the block select buttons (row of green or blue buttons at bottom of screen) to initiate a query of the block's parameters.

Reworked Amp, Cab, Rot, Cpr, Drv, and many other blocks:
- Reduced memory use
- Knobs replaced with faders, so Zoom feature can be used w/ more params
- Most blocks now use a set of common faders, with a row of switches to select between 'sets' of parameters. Params for these shared faders are queried each time you switch sets.

Other changes:
- Changed color of some buttons
- Set default skin = Flat
- Added a Zoom button to ExtControl page
- New look for Tap button
- Changed colors on many objects to look better with the Lemur4 skins
- Tweaked the size and position of some buttons and controls
- Moved some settings (favorite presets and some cc assignments) to a single container named 'aUser'
- Removed the legend text below the faders on ExtControl page
- Removed Close button on Preset page
- Removed Looper CC number dialog (these settings are hard coded in aUser.cMidi)

---Bug Fixes---
Cab block: cab type and mic type updating
Drive block eq controls fixed
Opening a dialog before querying the associated param would cause unwanted param change
Dialogs not initializing properly (2 bugs: resize problem, selection problem)
Removed a workaround for querying axeII amp type, not needed w/ firmware 9.02
Template was sending sysex & cc messages on load, this is fixed
Fixed some initialization bugs with muxed controls
Fixed some compatibility issues with Standard/Ultra
 
Outstanding!!!!
Minor bug: - switching scenes doesn't work (easy fix: "aUser.cMidi.gen2.scenescc" at dlgScenes.tap)

Wishlist:
- When pressing X/Y the template should resync
- in matrix view changing X/Y for any block should trigger a resync
- when switching scenes some block's X/Y might change, in this case, when leaving the scenes the template should resync

I couldn't make only the first one, but that's not the way Scrutinizer designed the whole AutoSync. In the cS.DoEveryFrame2() script should be a "if (X/Y changed) b=1". The whole template is too big to understand it 100%, I just couldn't code the "X/Y changed" there. (Not yet :) )
 
Thanks for the bug reports, and wishlist. I'll post v2.01 tonight.

Triggering resync if the XY state changes is best done in cS.upLedXY(). That function is already detecting the condition where controls need updating due to XY change. I have it working, just need to test to make sure it works with the mfc.
 
Thanks Scuntnizer for this new version!! It was already great now its even better. You are The Man!

Is there any chance to add functionality to reflect the FX state changes when one bypass or enable them from Axe front panel (or via other remote controller)?
 
prot, yes that's the goal. Auto Sync should work for the parameters and the bypass states and scenes.

Scene auto-sync might come later. I do not know if Scene# is included in the byp state message. There might be a new message for Scene# query that we have not yet seen.
 
This should work better.

https://dl.dropbox.com/u/54889552/AxeForLemur.2.01.zip

Change Log:
****************************************
Jan 20, 2013
Axe for Lemur version 2.01
When AutoSync is enabled, a change in XY state triggers resync of block params
When AutoSync is enabled, byp state button sync is improved
Fixed scenes CC# bug
Added support for the SceneNumber message (0x29), so Scene buttons sync w/ AxeII

Still no way to detect a change in byp state caused by MFC IA switch or AxeII front panel.
 
Scrutinizer,

On the looper page, is your implementation of ONCE (where it shuts off PLAY and ONCE at the end of the loop) a workaround that you came up with or does the AxeFx send sysex to signal the end of the loop? I'm guessing it's just timing on your end based on the REC and PLAY presses just because I'm pretty sure the AxeFx isn't sending anything related to that progress bar. Is that correct?
 
Scrutinizer,

On the looper page, is your implementation of ONCE (where it shuts off PLAY and ONCE at the end of the loop) a workaround that you came up with or does the AxeFx send sysex to signal the end of the loop? I'm guessing it's just timing on your end based on the REC and PLAY presses just because I'm pretty sure the AxeFx isn't sending anything related to that progress bar. Is that correct?
The AxeII can send looper status messages. This message includes the states of the looper control switches and also includes the looper position.

You can see how the message is formatted by looking at the template source code:
cS.HandleLooperStatMsg(msg) decodes the looper status message
SendLooperMonEnable(en) sends the message to the AxeII to enable or disable looper status messages
 
Back
Top Bottom