Hi, perhaps a good troubleshooting approach would be to disable any translators the produce output and then re-enable them one at a time until the problem shows up again. I’ll see if the developers have any other ideas.
I just thought of something else. I remember when I first got my BomeBox, that I had a USB device that was actually feeding back power into the BomeBox through the USB connector and causing it to misbehave. I’m wondering if maybe this is what is happening here. If you look at the Scenario 1 diagram that is not working, the really only change I see is that you have the BCF2000 USB directly into the BomeBox. Now since the BCF2000 is a device, it should not be providing power but maybe like my device (which was actually a powered USB hub), maybe it is. I think the BomeBox has protection from this but was warned that this could pose other side effects.
Maybe as a test, you can just set up your PC as a MIDI router and route the BCF2000 USB signal through the PC (project file would just be a line between input and output). Run the project on the BomeBox that way and see if the problem disappears. Bascially you would be using the PC to try and isolate a USB power feedback issue from the BCF2000.
If this fixes it, then we would have to think on how you could set up your USB connection to work from the BCF2000 directly to the BomeBox. I’m not sure if anyone makes “USB power Isolators”.
I started disabling preset one by one – narrowed it down to one preset. It appears the bug starts when ‘stop/start all controllers’ enables ‘Flash LED BCF’.
Hope something comes out of it.
Well that sounds promising. I know the APC Mini will crash if you send LED data to fast while moving the faders. The Behringer DDM4000 cannot handle incoming MIDI traffic for it’s LED’s if sending too fast (some LED lights don’t light but nothing else really bad happens). In both cases, we had to use MT Pro to slow down the MIDI data going into the controller to fix the problem.
However, if it is USB power backflow a USB islotator might do the trick. Looks like Amazon sells them (no surprise here as the sell just about anything you can think of).
I’ve just tested this with the BCF’s USB MIDI port not connected (as in physically unplugged). The problem still occurs- I notice it by the web app becoming super laggy after 2-3 minutes. I think it’s something with the Bomebox and that timer present.
What timer? Flash LED BCF?
Hmm, I was looking at your Flash LED BCF preset and I see you have a timer triggering itself which is usually not a good idea. The way are usually set up flash timers is this.
1) One shot timer to trigger a flash timer which is continuous at usually 100-500 ms.
2) Flash timer triggers an “Update LED” timer at a count of the number of LED’s you want to update.
3) LED update counter which iterates through all the leds (using count) to update them. I usually but a repeat delay of maybe 10ms so that I don’t overload data to the controller, but if you want to change the delay, you can change it in one place and you are done.
The update LED timer usually looks something like this. Say that gc is your counter, pp is the led number you want to assign for that iteration and qq is the value
gc=gc-1
// Set LED
if gc==10 then pp=15
// Set color
if gc==10 then qq=12
// Skip over rest
if gc==10 then goto “Done”
// Set Next LED
if gc==11 then pp=15
// Set color
if gc==11 then qq=12
// Skip over rest
if gc==10 then goto “Done”
… continue on until last iteration
Label “Done”
Outgoing action Raw MIDI 90 pp qq
Setting up the rules is a bit of a pain but once done, it works pretty good. Lots of copy and paste.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz
I mean preset ‘Flash LED BCF’- I still don’t know what about it causes the behaviour. But it appears that it starts when this present is enabled.
I’m not sure I understand correctly how you would set this up.
1 = initiate flash LED?
2 = timer interval?
3 = update LED which iterates through the LEDs with a timer with a really small time value?
My current setup was designed that flash LED was completely isolated from the rest of the project. So I can easily turn it off through ‘stop all controllers’ and quickly change the value of the repeat delay to control the amount of processing.
Works good on the laptop but seems to cause some unexpected behaviour on the Bomebox.
I’ll try to design something new for this.
Well I solved the problem by eliminating the self triggering timer. I’ve written a simplified flash LED script for tonight’s performance. I’ll restore it later.
I’m still very curious why this technique works on my laptop but makes the Bomebox behave this way.
Hi,
I’m glad you solved it. Timers can be very tricky things and if not careful, can cause performance issues. It can really depend on the host platform (BomeBox vs Laptop) and what else is going on.
I’ve written a demo (attached) that shows how I generally do my buttons.
I have two rows of 2 buttons each in this demo.
The top row handles solid on/off states (no flash timer). The bottom row uses a flash timer.
In both cases, I use a bitmap to control button states. I do this for two reasons:
- Less global variables
- Easier to do mass manipulation of bits with bit shifting, techniques (once you understand bit manipulation)
For the flash activity there are 5 translators
- Start the Flash timer at 500ms (1/2 second) intervals
- Kill the flash timer when there are no bits set
- The flash timer itself
- Iterate through all of the bits setting the LED state and updating the LEDs (this is a fast timer)
- Set Default state of LED’s when flash timer is killed (don’t leave them where they happen to be when you kill the flash timer.
I start and stop the timer using the same incoming note trigger, however the logic is to look at the LED states and only kill it when all LED’s are off (bit state is zero). I only start the timer if it is not already running. No need to restart it.
I set a kill flag when killing the flash timer and then use this to do a final note iteration to set the default LED state after the flash timer is killed.
I know it might be a bit overwhelming, at first but I find it a much cleaner way of doing things (once you get past the learning curve). With bit mapping technique, I can control 32 bits with a single global variable and update them all with one LED update translator timer (with lots of rules).
I hope you find this helpful!
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz
Attachments:
1536416323309_Flash-Demo-2018-09-08.bmtp
Hey thanks Steve, that sounds very promising. Could be very helpful. I’ll check it out soon. Bome is beating heart of my setup so there’s incentive enough to get it maximum efficiency.
Hi this might be a cleaner solutions. Uses presets instead of variables to start and stop the flash timer. Still iterates though notes to actually flash the LED.s
Attachments:
1536521777418_Flash-Timer-Control-2018-09-09.bmtp
Hi, happy to read about your solution. To shed some light what has probably been happening:
1) every time you start a timer, it creates a “thread” internally. You can ignore what that is, but it will block approx. 0.5MB RAM memory.
2) when you retrigger an existing timer, it might be that it’ll start a new timer and lets the old one die on its own (asynchronously). So for a brief moment, you’ll have 2 active “threads”.
3) now if you trigger new timers fast enough, there’ll be more and more active threads around. The BomeBox has approx. 32MB free RAM for the translation engine project, so if you create too many timers, you’ll hit a memory limit eventually.
4) A computer has much more memory available (so will not soon reach a memory limit), and its processor is much faster, allowing the processor to finish old threads faster, so that you’ll have fewer concurrent threads around with the same project.
Having explained that, it would still be nice if the BomeBox behaved better in such cases. The Bome MIDI engine should either reuse timer threads, or allow multiple timers per thread (which might hurt realtime performance). It’s now on our bug list to be fixed/improved.
Thanks for keeping calm… (I hope)!
Best regards,
Florian
Thanks for the detailed explanation, Florian! This all makes sense. It also tells me that having less timers and controlling them as I did in my project files should help alleviate the issues.
It the solutions I posted, each only has at most 3 active timers.
1) One shot timer to start the flash timer
2) Continuous flash timer to trigger the LED timer at intervals as specified in the one shot timer.
3) Counter based LED timer to actually update the LED’s. This one runs much faster and the number of iterations (LED’s to control) are determined by the variable set in the flash timer.
The flash interval is controlled by the flash timer and the LED update speed is controlled by the LED timer. No need to have different timers for each LED under control. The other positive thing about this strategy is the if you use a single LED timer controlled by the flash timer, then the LED’s flash in sync (or pretty close).
Most of the heavy lifting (rules) such as note, numbers, and velocities (colors) are handled within the flash timer, so if you need to change which LED’s to flash and what color, it can all be handled there in rules of this translator.
Steve
Thanks for the explanation – I do see how that couls result in performance issues. I’m also happy to hear that it’s on the bug list.
I’ve created a simple project with just the self repeating timer (at a 2000 ms interval so should barely lead to any processing problems) and a single note on/off translator. Same problem occurs after a short while. If i am correct this should lead to at most 1 MB RAM (old timer and new timer) in use which technically could never be a problem for 32MB memory.
I’m not sure if I recall this correct but I remember that the problem only occurred on the DIN port but I’m not sure whether that right.
I you want to post the file, I’ll have a look. Does the problem only occur if the project is running in BomeBox or does it also occur on your computer?
I don’t know how to respond with an attachment – it gives me no option to include an attachment when I try to post a comment under the appropriate response so I’ll do it like this.
I’ve included a very simple file with the self-repeating timer. I did not test this specific one my laptop but it does bug my Bomebox after about 2-3 minutes. I added a 60 second interval before the timer starts.
@Steve I downloaded your MT files but I have to admit I have no clue how bitmaps work. Do you utilize them sort of like an array of on/off values?
Attachments:
1536697010548_Self-Repeating-Timer.bmtp
Thanks, I’ll have a look.
Yes, I use bitmaps as a bit array. Each bit represents a LED state 1=On and 0=Off.
Since Bome variables are 32 bit signed integers, I can control 64 pads with only 2 global variables to depict the on/off state of a given LED.
For controlling lights I typically just update a given bit’s state instead along with sending the MIDI message to the device I’m controlling. I can then use a single timer to read the bitmap and update all of the led’s by iterating through the bitmap. The only time I have to change variables is when when I change from the first group of 32 to the second group.
It is a bit of a pain to set up but once you get the logic, it is a much more maintainable project.
Steve
I think I get how it works … in theory.
Now do something practical with it. I do eat through variables quickly to store stuff so this could really improve my project.