Automation Template - too many translators?

Bome Products
1

So I’m trying to avoid a huge amount of work making translators. First, I’ll explain how this project works:

 

The goal of this template is to have control over which parameters are linked to which knobs on my Midi Fighter Twister, in conjunction with my Launchpad Mini.

 

I've split the MFT into 3 sections:

 

Global Knobs - Top row: Green, Yellow, Orange & Red knobs control all enabled parameters, represented by the color of the associated pad on the Launchpad.

 

Local Knobs - Middle 2 rows: These knobs represent different parameters based on what column/row menu Launchpad buttons are pressed. If none are pressed, they represent "Master" parameters, which route straight to the DAW. LEDs match color of global knob linked. If no knobs are linked, they are blue. These knobs will still control a parameter, even if it is linked with a global knob.

 

The behavior of each pad depends on the "mode" of the row it is in:

 

Green - Toggle: Press on, Press off

 

Yellow - Momentary: Flips on/off when pressed, flips again on release.

 

Orange - Solo: Press a pad, the rest in the same row turn off. You can press multiple pads simultaneously. All pads will return to their original state upon release.

 

Red - Lock: I'm not sure if I'll use this for something yet, so for now it just locks the row from triggering. I can still assign pads to different knobs though.

 

Part of my idea was to create banks of parameters that I can browse through to assign parameters to their own locations. This would allow me to recall entire presets of button & parameter arrangements with the press of a button, all without interrupting playback in FL Studio. (the only way to change the knob a parameter is linked to is to unlink it and then relink it, which may interrupt the plugin)

 

At first I was concerned with my remaining global variables, so I learned how to use the bit operators to hold all 64 toggle values into 2 global variables. Worked out well so I just started making the translators for the parameter banks.

 

I created all the translators for a couple parameters and then realized that I’d have to make a MASSIVE amount of translators to achieve the bank system I want...considering that BMT is the only bit of programming experience I have, I bet there’s a better way to go about this that I’m not seeing.

 

I’ve attached my project if you want to take a look.

If anyone has any questions just let me know!

-TallGuyWithBeats


Attachments:
1578545968651_TGWB-Automation-Template-v5.bmtp
2

Hi,

 

This is quite a script and you are using a lot of variables but I can't see where you are documenting anything anywhere so I have really no clue on your intention for the various presets and translators you have created.

With that said, in general, I usually do more with rules to achieve creation of less translators.

I usually set up presets for either major behavior changes or for different MIDI input/output behavior.

In order for me to assist more, I would need to to somewhere document each global variable and what they are used for.

For me, I usually document global variable under an INIT preset under a translator "Initialize Globals" (even if they don't need initialization). I then include them all there in alphabetical order. This translator is fired with a one shot timer "init" which can be triggered when project opens or any other incoming action you want to set.

I think I get the idea of what you are trying to achieve (different behaviors of knobs on the MFT depending on the buttons pushed on the Launchpad MINI) however right now it is too complex to get my head around since it is not well documented.

I did, however notice some of your timers are looking at a variable "oo" which doesn't make sense since that is a local variable and is not guaranteed to have any value. These are the timer "Check" under preset 35.

Also in preset 2, you might be able to reduce translators of 5-12 into a single translator using the note value as a variable instead of different translators to determine which button was pressed.

Instead of the hard coded note number, simply use the variable qq which you set later in the rules anyway.

So if you need my help further:

  1. Reduce the project size down to a minimal and document using comments what you are intending to do
  2. Document all global variables

Steve Caldwell

BomeQ AND A Moderator and

Independent Bome Consultant/Specialist

bome@sniz.biz

 

 

 

3

It would also help to see a configuration file for your MIDI Fighter twister as it can be programmed in several ways.

4

Thanks for the tip, Steve.
Currently all my notes are in a very disorganized Google sheet (I do most of my brainstorming away from home), so I’ll sort things out and get back to you with a slimmed down project with comments.

5

Hi,

Yes you have 700 translators. I actually wrote an awk script to read the exported text file and figure out where you were using each global variable (in rules). I've attached the output as a FYI.

I run the script on cygwin which is a Unix lookalike programming layer under Windows.

Each line show the preset/translator number, the name of the translator and the global variable that was used within the rules section of that translator. Quite handy for very large projects. The script is not bullet proof but captures the majority.

Steve Caldwell

Bome Q and A Moderator and

Independent Bome Consultant/Specialist

bome@sniz.biz

 


Attachments:
1578677055141_TGWB.txt
6

Hi Steve,

Hope you\'re doing ok out there.

 

After reviewing this for the past several weeks, I realized I was able to SIGNIFICANTLY reduce the amount of translators I need. (I got rid of some other functions, so I think I\'m under 100 now lol)

The only thing in struggling with now coding the behavior of Solo mode. Here\'s a quick recap of the pertinent functions, so you don\'t have to reread anything:

 

Global Knobs- these four colored Midi Fighter Twister knobs change the value of parameters linked to them.

 

Pads- the 64 pads on the launchpad represent 64 parameters. When they are on, the LED is on and the parameter can change. When they are off, the LED is off and the parameter cannot be changed by global knobs.

 

Color Shifts- the bottom 4 knobs on my Midi Fighter Twister, when pressed (not turned). When held, the pad I press changes to the color.

 

Menu Buttons- The top row and right-most column on my launchpad (the smaller, circle buttons)

 

Row Mode- by color-shifting the row buttons, I change the pad behavior of the corresponding row. Toggle and Momentary modes are working fine, so Solo mode is the only thing I\'m focusing on right now.

 

Here\'s a breakdown of the intended Solo behavior:

 

If no menus or color-shifts are held,

ON PAD PRESS (90 oo 7F):

// Solo is active

- Turn off Values (on/off) & LEDs of unpressed pads in current row.

- Turn on Values & LEDs of pressed pads in current row.

 

ON PAD RELEASE (90 oo 00):

- If no pads in the current row are pressed (solo = inactive),

-- Revert Values & LEDs to original state (before Solo was active) of all pads in the current row.

- If some pads in the current row are still held (solo = active),

-- Turn off Values & LEDs of unpressed pads in current row.

 

If menus or color shifts are held,

ON PAD PRESS:

- Change LED color based on the menu/shifts held

// This should not turn the LED on if the pad is disabled.

// Menu + Press will unlink the pad (from the global knobs), changing the color to the default light orange

 

ON PAD RELEASE:

- do nothing

 

I can\'t seem to wrap my head around doing this without creating a lot of timers, which also means more translators. Any ideas?

Thanks,

TallGuyWithBeats

7

Well in general if I do LED manipulation I set up bitmaps for each pad and timers to iterate through the bitmap and change the pads\'s state. Of course bitmaps are usually just 2 states (on and off) so I usually use rules and different presets to control the on off colors but I suppose you could do it with bitmaps too. For instance for 4 colors you need 2 bits, for 8, 7 bits. So for 64 pads controlling 2 colors, you can do this with 2 global variables (which are 32 bits). If you want 4 colors you will need 4 global variables. The trick here is the logic for setting and clearing bits. This is where the bit shift, AND, OR and Exclusive OR operators come in. It is rather a pain to set up but once you get the logic right, it works like a charm, If you search on the board for APC-MINI and/or bit mapping, you should find an example of what I did.

I suggest before you do any coding, you flow out the logic with a diagram. Then decide, on your bit mapping strategy and you preset enable/disable strategy. As part of bit-mapping, you determine which global variables to use and which bits represent which pads. You set up separate routings to just set and clear bits when pushing buttons and then use the note-on and note off messages that you use to trigger your iteration timers for LED update.

That\'s probably about as deep as I can go without jumping into code itself. Somewhere on the forum I also put in some basic recipes for setting and clearing bits. If you can\'f find them, let me know and I\'ll see if I can dig them up.

EDIT - Just reading back to your initial post. Looks like you are already into bit manipulation. Didn\'t notice that before. I hope the rest of my answer helped though.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

8

You shouldn’t need too many timers though. Really just one to update the LP MINI with the 80 LEDs. YOu can put the same incoming timer under different presets and just change the on-off colors to different ones if you want under that preset. Timers could all have the same name but only the then active preset incoming timer will fire.

9

Thanks for the suggestions, Steve.

I was using bitmaps for the pad on/off states before, but after struggling so much with the logic (especially when working on solo mode), I changed it. I figured that I already had 64 variables used to hold the color states of all the pads, so I'd use the same variables to hold the pad state as well:

- 5 color states per pad: Unlinked (Pale Orange) (0), Green (1), Yellow (2), Orange (3), Red (4).

- Each pad can be on or off.

- Each color state variable (ga, gb, etc.) is either Off [0,1,2,3,4] or On [10,11,12,13,14]

With this, it was much easier to grab the current value of any pad when in Toggle or Momentary modes, since it was hard-linked with the LED state. But, now that you mention using bitmaps for the LEDs, I'm wondering if the hard-link is the reason why I'm having a hard time with Solo mode.

I've attached the project (which should be much easier to sort through now), if you want to take a look.

I'll try creating a diagram to help me see how it all pieces together.

-TGWB


Attachments:
1589503446965_Autostation-051420.bmtp
10

Well your project looks well organized and it looks like you have listened to many of the tips I provided before.

The support you are asking for is beyond the scope of free support offered here, I can probably still provide you a few tips or suggestions, but I don't think I can do a deep dive into the troubleshooting and design of your project as part of free service. I might be able to help further, however if you want paid services. Just drop me an email for my pricing.

With that said, I DID notice something that did not make sense to me. Tranlatoer 3.2 extensively manipulates the value of local variable rr, however I don't see where you use it on output or move it to a global variable so I'm afraid nothing will ever see all the work you did with it in that translator.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

 

11

Good catch with variable rr in translator 3.2. I think I had overlooked this code because it was left over from when I was working on translator 3.3, for the LED states. I can't test it out right now, but it seems I can remove these lines without repercussions, not just for 3.2 but also for 4.2 (almost the same code, just in Momentary mode).

Regarding paid services, I completely understand and will definitely consider it!

Thanks,

TGWB

12

Sounds good. It is almost always harder to evaluates someone elses code then to build it yourself primarily due to not having context. It usually takes a few hours to just figure out the current structure by the creator before you can actually start working with it.

Steve