On Mon, May 9, 2022 at 10:07 PM, Alf Schroth wrote:

add additional memory to the FCB101, maybe on a daughter board that can be installed

The LG-FCB upgrade kit did exactly that (http://www.lg-fcb.com/) . It was on the market for a few years (with little to no success) - it has been replaced by the external TinyBox.

--
Regards,
Alf
🪗 🎶🎤

Yes, it is amazing what you have done with 30 year old technology!  You would think that at some point in time, Behringer could make an updated product with more memory and more functionality. But then again, it is probably good business for you that they haven't.  I use UNO2 on this one to control my Nord Stage 2 EX and my Hammond SK2. 

I also have a Nektar Pacer, that has way more functionality (but no SysEX). Also, I have to attached external expression pedals as it has none of it's own.  It has 24 banks (they call them presets) and an additional 2 special banks. One for DAW control and the other for transport control.  It also has USB functionality (including power).  I'm sure they are likely selling a lot of these.  There is also an online editor to program this device. Right now, this is my primary device for controlling things at my desktop computer.  

I also have a FC-300 (bought used) but it can only be programmed through the tap-dance method or sending a SysEX dump. No editor.

On Fri, May 6, 2022 at 11:24 AM, Jack Fenton wrote:

Maybe more of a Macro than a function as there are no function parameters or return value.  I'm working on a project and tried this technique to reduce my footprint but was unsuccessful, because I still had to set variables before calling the SendTrigger

It might be nice to introduce this concept of a function in the UnO2 "programming language", (I would definitely call it "function", all programming languages do support parameterless functions without return value). It would still do exactly the same as what you can do now, but it might be less confusing than reusing the SendTrigger construct as we do now. This would also allow to introduce optional function parameters, something you have to do now by setting a variable prior to calling the "SendTrigger". But again, in the end it would do just the same and therefore consume the same amount of resources.
I think that's the biggest issue with this whole UnO2 approach : it might look like you can do things which are obvious for higher programming languages running on a computer, but you should not forget that the code needs to get compiled into something that can run on a 30 year old 8-bit microcontroller with very limited resources. That's the main challenge... 

That would be awesome, thanks!

At some point in time constants have been part of the TinyBox (and now UnO2) programming language. I even used the exact same syntax "CONST #... ", next to "VAR $... " 
I removed it for the sake of simplicity (both for the user and for me...). I will add it to the feature request list again as a possible nice-to-have feature.

Any thought of using constants in Uno2?

Right now I'm using a bunch of VARs that take up space but I don't modify.  I could use absolute values in the cod but for readability I use VARS and maybe have a constant construct of sorts would help make the code look more readable without using VARS.e

So for something like this (if the value never changes

VAR $Sustain=64

Use 

CONST #Sustain=64

And then throughout the project instead of using

SendMidi Nord  CtrlChange $Sustain 0

I could use this and not consume any variable space but still make it easier to read my code

SendMidi Nord  CtrlChange #Sustain 0

Which would be easier to read than

SendMidi Nord  CtrlChange 64 0

Maybe more of a Macro than a function as there are no function parameters or return value.  I'm working on a project and tried this technique to reduce my footprint but was unsuccessful, because I still had to set variables before calling the SendTrigger.  I think I will end up starting from scratch now that I've learned a few things about memory use. It would be helpful to document any other tricks that can be used to reduce the memory footprint. 

I have a bunch of SysEX messages programmed so I think that is where most of my memory is being eaten up. Most of these have the first same 5 bytes so it would be helpful if I could figure a way to string pieces of a SysEX message together to save memory space, like building some sort of byte array.

I assume memory strings are likely actually tokenized by the compiler (editor)  before sending to the FCB1010. I assume also complex conditional logic chews up a lot of memory so structuring in an efficient way (perhaps for reuse like SendTrigger) might be a good technique.

On Fri, May 6, 2022 at 10:40 AM, <clippeh.kulinski@...> wrote:

I am a bit confused about SendTrigger and SwitchOn

These commands are very similar : SwitchOn/SwitchOff sends all commands defined in the effect content, and adapts the switch LED if this effect is linked to an FCB1010 switch . SendTrigger sends all commands defined in the trigger content, but doesn't adapt any LEDs (as opposed to an effect or a preset, a trigger never results in a switch LED staying ON)

The trick here is that we don't define the trigger in order to link it to an FCB1010 switch. We just use it to create what you could call a "macro" or "function" with a reusable command set, which can be triggered from various different presets. 

I noticed a few errors in the GuitRec Triggers (unfinished). Can't remember if that was me or you, but I fixed it and it works perfectly!!

I am a bit confused about SendTrigger and SwitchOn but I'll double check the documentation. Thankyou for the help Xavier. As I said I'm no coder so I knew there was a better way of doing this.

Now I can pack a bit more functionality into my FCB1010+UnO2!!!

Thanks again,
Oliver

The best way to save setup space, is by putting a series of commands which are sent by multiple presets in a trigger content, and then in all those presets have a single call to "SendTrigger nnn", instead of repeating all the commands each time. 
I don't know if in your setup it would be OK to first disarm all tracks, and then arm the required track. In that case you could have 1 trigger which is used in all presets to disarm all tracks, and then 1 command to arm the correct track. 
I rewrote your setup that way, and reduced the used space from 99% to 66%

Hi,

I'm going to explain too much but if you can, can you just tell me if my attached code can be condensed any more?

Some information: I have the FCB1010 with UnO2 installed. I use Ableton live 11. I've written a ~1000 line code which allows me to control 9 tracks for 9 different instruments (5 Guitar and 4 Piano) and record 5 clips on each instrument (buttons 1-5). This basically works well for LOOPING in session view of Ableton. In the code all elements refer to Guitar because I'm lazy and am not sure if this will be my final setup. I may make a video of how this setup works but I would need two cameras going to see what's going on.

This is what the banks look like. It looks unfinished because I have no memory left. I've even used the direct bank because it reduces the memory cost by a percent or two.


I've attached my code (Some small note regions and one large region, "//ARMING TEST" is a note because it is only required temporarily for MIDI mapping the track-arm button in ableton).Could someone look at my code and tell me if there's any way of condensing it to save memory? I feel like there is something I can do but I'm no coder.

The idea is: 
"//Silences" contains scripts that are triggered to disarm all the tracks except for the track corresponding to the bank of the preset selected. CC10 is bank and track 1, CC20 is bank and track 2, so buttons 1-5 of bank 1 will silence the other tracks, allowing one instrument to be switched to.

"//ARMING TEST" is what i explained before, just necessary to map CC10,20,30 etc to each track arm button in ableton, then it is disabled.

"//COMPLETE" is the good stuff. It has a conditional statement that sends a NoteOn 11 127 (corresponding to track1, clip1 in a custom FCB1010 remote script). This means button 1 of bank 1 selects track1, clip1, and records. It will record ONLY IF button 1-5 of bank 1 is the last button that was pushed (the track is armed)... That's what the statement is for every single button, 5 buttons on each of 9 banks = 45 buttons for looping.

Yeah.. that's it... It makes sense to me!

UNNECESSARY INFORMATION BELOW
Here's MORE information if you're really interested in doing what i've done for yourself, or want to understand my code setup:

If anyone knows about the FCB1010 MIDI controller remote script (based on the APC40) that's floating out there in the internet, I'm using a modified version for Ableton 11. Some of the MIDI mapping I've coded mirrors that in the script. It just means I get easy access to functions such as Undo/redo in ableton, metronome, and clip slot select/record. The only thing I have to map in Ableton manually is the track arm, which i've coded specifically to DISARM all other instrument tracks (disables tracks THAT CAN BE SELECTED BY THE FCB1010 (ie. disables 8, arms 1)). Yes it's a little confusing to explain but it is working very well for me at the moment. I've only had JUST enough room to code separate expression pedals for 4 banks (allowing 4 instruments to have it's own individual use of the exp pedals). Confusingly, I've put expression1 starting on the second bank, as I'm using the first bank for recording bass (i won't need an exp pedal for this).

That's the rundown. I will explain a little more if you want to know what's going on, but without the FCB1010 remote script this will take a long time to MIDI map in ableton by yourself, and you won't have access to the Undo button (button 6 on the FCB). If you do want to try it all. I can send the FCB1010 remote script (MUST HAVE ABLETON 11), and my ableton template. The template will save a lot of hassle of trying to map CCs to the arm button for each track (you have to disable the majority of my code, leaving the ARMING TEST section, make the MIDI map, and then reenable the rest of the code)


I've totally explained way too much. Could you just tell me if I can condense my code at all?

Ollie