API return values and strange issue

KD0RC

K5CG

Any chance you could  build an Arduino solution for the Behringer CMD Micro?

KD0RC

John G3WGV

K5CG

@KD0RC There are lots of threads about it here on this community.

For example (with pictures)
https://community.flexradio.com/flexradio/topics/manual-instructions-for-the-behringer-cmd-micro

But really, any MIDI DJ controller would be fantastic and it might simplify your hardware development with lots of knobs and LEDs to take advantage of.

K5CG

And Carl, before you jump in here and tell us Pegasus Plus does this, no it doesn't. Not the way I want it to. It's inflexible. Sorry, walk away from the keyboard.

KD0RC

KD0RC

John - you are genius!  The double worked to get rid of the odd rounding at higher frequencies.  Now I just need to do a little digging through to find out why some functions can be set but not read.
Len

KD0RC

So, are those virtual knobs on a screen or physical knobs in a box?

John G3WGV

Glad that bit worked. Some thoughts on the audio level stuff:

When you open a slice, a ton of information about that slice is sent, including the audio level at that time. In general, if you subsequently change a parameter then that change is sent out to all clients except the one that originated the change. The logic is that the originating client knows it made the change so there is no need to tell it again.

However... earlier versions of the FlexRadio API didn't strictly keep to this general rule. So some but not all updates would in fact be sent back to the originating client. Over time, the Flex code writers have been fixing these logical errors as they find them.

Now, if Enzo's code assumes that an audio change is going to be sent back to his code but in fact it is not then you will get the exact problem that you are reporting.

I remember that I tripped over this problem with slice mute, which was but now is no longer sent back to the originating client. It would be no surprise at all to find that the same thing happened along the line to audio level changes.

Something to look into!

73, John

KD0RC

That may well be the issue. Mute does, in fact, behave the same way as audio gain.  Both initially report back from the radio as zero, so I set them to Slice A unmute, vol 30 and Slice B mute, vol 30.  That way I get a predictable starting point for both slices.  I will poke around in the libraries to see if I can figure out how to get the audio gain and mute to read without first setting them.
73,
Len

KD0RC

I see that you use a 1 - 16 multiplexer for your switches.  I probably should have done that.  Instead, I use 10 Arduino pins arranged (logically, not physically) as 5 rows and 5 columns to get up to 25 buttons.  The 5 rows are interrupt driven, then I scan to see which column is selected.  Software works great, but the wiring is a real mess!  I made a mistake in assigning the pins sequentially as R0, C0, R1, C1... instead of R0, R1, R2...  C0, C1, C2...  Counting rows and columns amid the rat's nest of wiring is much harder this way.  If I buils a V2 of this thing, I think I will try the Teensy 4.1 (PJRC.com) with the built in ethernet.  I will definitely take your lead and use a multiplexer for the switches.  You can probably tell by now that I am a ham, not an engineer.  : )
73,
Len

John G3WGV

Just to be clear, the issue is not that Enzo's software doesn't read these messages. The problem is that the messages are no longer sent from the radio to the initiating client. So instead of the client relying on the radio to set the new value for that control at the client, the client has to do it for itself. Because that is not happening, each time you come to update it (e.g. you turned the audio up) you are starting from the slice startup value rather than the value from last change you made to the control.

It can be a bit of a challenge to get your head round what is going on here!

John G3WGV

On multiplexers: I originally planned to do what you have done but quickly concluded that multiplexers was the way to go. I actually use two, so that gives me 32 switches from a total of six pins (four address, two mux chip select). It works perfectly and is much simpler to wire (and to code).

KD0RC

John G3WGV

KD0RC

Thanks John, I really appreciate the help!  I have not really needed to change much so far, but I think this one will require some thought. I will poke around and see what I can come up with.
73 and thanks again,
Len

KD0RC

Brilliant John!!  That was it.  I changed the command to "audio_level", and it works perfectly!  Hopefully, my understanding is getting better and I won't have to come back for more help.  Now I can get back to wiring up the rest of the switches and lights and finishing up the code.  Next challenge will be to find a suitable enclosure instead of the cardboard box.

73,
Len

John G3WGV

Happy to be able to help. I had great fun building my controller and I'm still making improvements to it, three years later! I hope you get the same satisfaction out of the project and then being able to use your own controller in the pileups.

73, John