Issue with Case Construct UNO2 1.3 #UnO2


Jack Fenton
 
Edited

Hey I'm not sure what I'm doing wrong here.

If I have $DEV = "Hammond" then everything works fine in selecting different sweeps, but if it is not "Hammond" (it would be "Nord). All I get it the last Hammond Setting. Maybe my case construct is wrong but I've been pulling my hair out for hours.

TRIGGER_CLICK DevExp1Select =
{
    switch($DEV)
   {
      case "Hammond":
           switch($HammondExp1Type)
         {
            case "Swell":
               Pedal 1 = SWHammondVol 
               $HammondExp1Type ="Vol"
               break
            case "Vol":
               Pedal 1 = SWHammondSwell 
               $HammondExp1Type = "Swell"
               break
            default:
               break
         } //switch($HammondExp1Type)
  break // case "Hammond"
        default:
           switch($NordExp1Type)
         {
            case "Swell":
               Pedal 1 = SWNordMaster 
               $NordExp1Type = "Master"
               break
            case "Master":
               Pedal 1 = SWNordCtl 
               $NordExp1Type  = "Control"
               break
            case "Control":
               Pedal 1 = SWNordSwell 
               $NordExp1Type = "Swell"
               break
            default:
               Pedal 1 = SWNordSwell 
              $NordExp1Type = "Swell"
               break
         } //switch($NordExp1Type)
         break 
   } //switch($DEV)
   SendPedal 1
 } //TRIGGER_CLICK DevExp1Select 

I think it was working on 1.2 but I now how the 1.3 chip so not sure and don't want to go back and re-install the old chip.



Jack Fenton
 

I might end up going back to  UNO2 1.2 .  Many things that were working before no longer work on UNO2 1.3. I suspect that 1.3 has some serious bugs.

Is anyone else experiencing issues with 1.3? Particularly around case, if, else if, else statements related to string lookup?


savilior@...
 

The switch seems ok. However you did not include the call to the trigger so we cannot be sure that the$dev variable is other than Hammond.

Try to debug that on entry to the function with Nord the $dev is indeed something other than hammond


Jack Fenton
 

Yes, I know that $DEV is set correctly.  I've spend hours on this and it seemed to work perfectly with the old UNO2 firmware so I'm pretty sure ether there is a bug in 1.3 or the 1.3 editor.  Are you  running 1.3?

The only thing I added to this code is the SendPedal 1 construct to debug whether it was properly getting set without having to move the pedal again. (New 1.3 feature).  I'll wait to hear back from ossandust before I try and tackle this any more. 

I also move it to an if , else if, construct and it is still not working. All I get for the Nord is Swell but Hammond properly switches between Swell and Volume.

I haven't even tried to tackle Expression 2.  Also, I have a similar construct for sustain pedal select that is not working that was working with UNO2 1.2



savilior@...
 

That's interesting having problems as program flow and variables statements are fundamental. I am still waiting for a 1.3 to arrive so I cannot debug. Sorry, but yeah, ossandust can sort it out :-)


ossandust
 

I will have to look into it when I get home, which is not the first couple of days... 
Those hierarchical conditional statements (switch within a switch) were quite complicated to implement in assembly language, so something might have gone wrong there while adding the new v.1.3 conditional statements. I created an extensive automated testing system, but it clearly can't cover all combinations of all features. Makes me decide to stop adding yet more new functionality in UnO2 firmware, maybe just in the TinyBox firmware. Upgrading the Tinybox with a bugfix is just a matter of one click, upgrading UnO2 is impossible - except by sending around new chips which is too much of a hassle. 
Of course I need to make sure the available functionality is 100% bugfree.


Jack Fenton
 

Thanks,

I also tried if, else if and else constructs but had similar problems. I originally thought also that it might be "case" nesting problem.  I may end up going back to my original UNO2 chip if I can't figure it out.  I understand the mailing chips is a pain so I might just ask for a refund instead of an replacement if you confirm it is broken.  The original 1.2 chip worked fine but just didn't have the new functionality of 1.3 that I was looking for.  I'm also a bit disappointed that the SysEX sweeps don't work as expected in 1.3.  I may just end up going to Eureka3 PROM in IO mode and use my BomeBox to handle all of the heavy lifting. I really didn't want a separate box, however (TinyBox or BomeBox).

A shame that Behringer cannot just create an "FB-2022" that has lots more ram and with flash memory for upgrading. The form factor is really nice and it really is ripe for having something similar that does what TinyBox does without the need for an external controller.  I'd use my Nektar Pacer, but with that it requires external expression pedals.  Pacer also has USB so that is really nice.



savilior@...
 

If I may, I can offer to help. I mean, just throwing an idea here. The community of UnO is quite techy so I can see a few extensive users which have background and can volunteer to be beta testers few months before issuing a new version. As such, I have experience as beta tester and went through VP QA and VP R&D positions in few start-ups (one of which designed HW) so I can QA. At that I mean I can set up an EPROM programmer to speed up the turnaround of test - fix cycle and cut down the costs of doing so to practically zero.


ossandust
 

v.1.3 has an issue with string variables indeed. It can be worked around easily by using int variables instead. Maybe a little less elegant, but by adding comments it's almost the same : 

VAR $DEV = 2 // Nord
VAR $HammondExp1Type = 2 // Vol
VAR $NordExp1Type = 1 // Swell
 
TRIGGER_CLICK DevExp1Select =
{
   switch($DEV)
   {
      case 1: // Hammond
         switch($HammondExp1Type)
         {
            case 1: // Swell
               Pedal 1 = SWHammondVol 
               $HammondExp1Type = 2 // Vol
               break
            case 2: // Vol
               Pedal 1 = SWHammondSwell 
               $HammondExp1Type = 1 // Swell
               break
         } //switch($HammondExp1Type)
     break // case Hammond
      default:
         switch($NordExp1Type)
         {
            case 1: // Swell
               Pedal 1 = SWNordMaster 
               $NordExp1Type = 2 // Master
               break
            case 2: // Master
               Pedal 1 = SWNordCtl 
               $NordExp1Type = 3 // Control
               break
            case 3: // Control
               Pedal 1 = SWNordSwell 
               $NordExp1Type = 1 // Swell
               break
         } //switch($NordExp1Type)
         break 
    } //switch($DEV)
    SendPedal 1
 } //TRIGGER_CLICK DevExp1Select 
 


ossandust
 

Let me know if that covers the "Many things that were working before no longer work on UNO2 1.3.". I want to know if I can work on creating a next release, or if I need to investigate anything else first. 


ossandust
 

Side remark : 
it is also possible to keep using string variables, and avoid the firmware issue by adding a few unused dummy string variables before the actually used variables : 
VAR $DUMMY1 = ""
VAR $DUMMY2 = ""
VAR $DUMMY3 = ""
VAR $DUMMY4 = ""
VAR $DUMMY5 = ""
VAR $DUMMY6 = "" 
VAR $DEV = "Hammond"
... 
You will also need to remove the "default:" section of the switch statement 


Jack Fenton
 

Hi @ossandust,

While, I appreciate you taking the time to show me "workarounds',   perhaps you can just send me the fixes when you have them (I'm not in a hurry) or refund my purchase and I will go back to my old EPROM that seemed to work correctly.  I'm still amazed at what you have been able to accomplish with such little FCB1010 memory. I'm not interested in an external box, to control the FCB1010, but I would be interested in having a firmware solution that worked.  I prefer my old firmware (that works) over new firmware (that requires workarounds).

If I have larger projects that FCB1010 doesn't handle, then I will use my existing BomeBox with EureakProm in IO mode which will allows me to control the FCB1010 and also other devices without making any hardware mods to my FCB1010. 

For simpler projects, I still have my FCB1010 (different one) that I'm running UNO 1.0.4 that handles most of my needs.


Thanks for looking into this all though!



ossandust
 

On Tue, May 24, 2022 at 03:19 PM, Jack Fenton wrote:
While, I appreciate you taking the time to show me "workarounds',   perhaps you can just send me the fixes when you have them (I'm not in a hurry) or refund my purchase
I will not send you another chip, because you might well find some other feature which doesn't work as expected and for which you are not willing to use a simple workaround, so I will refund your purchase - I guess one has to pay the price for writing bugs... 


Jack Fenton
 

Yes, thank you!  I know the situation is difficult when you don't have the convenience of having firmware that is downloadable.  Maybe the TinyBox is really the best solution for most people because it has less limitations and can be upgraded remotely. Again, it is a shame Behringer has not invested in a follow-on solution. Eventually the FCB1010 will not be the cash cow as it is now.  For most applications I've abandon it for the Nektar Pacer, but again that device doesn't have any built in expression pedals which I like to use on my FCB1010.  The Roland FC-300 does but less pedals and a pain to program.





ossandust
 

On Tue, May 24, 2022 at 07:30 AM, ossandust wrote:
Let me know if that covers the "Many things that were working before no longer work on UNO2 1.3.". I want to know if I can work on creating a next release, or if I need to investigate anything else first. 
with no further feedback about possible issues I have released v.1.4 and resumed shipping UnO2 chips. Changelog : https://www.fcb1010.eu/downloads/uno2_changelog.txt