PD multiplexer capelet example

ManosDim

Thanks so much, It is working. The next question is if I could use the multiplexer as digital/analog outputs and inputs at the same time. Will I write to a table with [tablewrite] and the index/output the value (0 to1) that I want?

giuliomoro

ManosDim f I could use the multiplexer as digital/analog outputs and inputs at the same time.

no, the multiplexer only allows to increase the count of analog inputs. The digital I/O and analog outputs are unaffected.

vfillion

Hi @giuliomoro ! Are the values stored automatically in the array in PD ? I am getting the regular C++ example to work with my Multiplexer, but have not yet succeeded on PD. When I run the example, I'm not getting any readings, everything's at zero. Do you somewhere have a tutorial on using the multiplexer with PD ? Thank you so much.

giuliomoro

vfillion Are the values stored automatically in the array in PD ? I am getting the regular C++ example to work with my Multiplexer, but have not yet succeeded on PD. When I run the example, I'm not getting any readings, everything's at zero. Do you somewhere have a tutorial on using the multiplexer with PD ? Thank you so much.

Sorry for the late response, I missed that. The example is on the board on PureData/multiplexer-capelet. You'll need to update your Bela core code as explained here if you are using a Bela Cape Rev C.

abas

Going off of your response giuliomoro;

If I'm trying to get the first column elements such as 0.0, 0.1, 0.2, 0.3 then I would feed the objects [tabread bela_multiplexer] the values 0, 8, 16, 24 respectively. Correct? Like so:

The issue I'm getting is that the first potentiometer which has its middle lead connected to 0.0 of the multiplexer somehow change the value of all elements in the first column. I have the multiplexer capelet set to 64:

When I run the given Pure Data Multiplexer Capelet example I get the same behaviour. The first pot affects the first element of all rows. My 3 other pots do nothing. I've checked for shorting and connections on my breadboard and all appears to be correct. Lastly, I have all my pots connected as in the examples provided such as here: https://learn.bela.io/tutorials/c-plus-plus-for-real-time-audio-programming/analog-i-o/

In other words,

left lead connected to 3.3V (So max value goes to 3.3V)
middle lead connected to appropriate Mux input (0.0 for first pot, 0.1 for second and so on...)
right lead connected to ground (So min value goes to ground

Any help would be appreciated

PS.

giuliomoro

I assume you are using a Bela Cape Rev C ? Follow the instructions here to update your Bela core code and that should fix it:
https://learn.bela.io/using-bela/bela-techniques/updating-bela/

abas

I did the update and then had the same issue.

But I realized that I forgot to change the bela_multiplexer array in PD to the appropriate size (in my case, 64).
Now it works as expected. Thank you!

abas

giuliomoro

No worries, so now that I've gotten the Mux figured out, I have encountered an issue where my system now prints "Underrun detected: 1 blocks dropped" over and over on the screen. Here's a screenshot of the IDE:

I'd assume that this is probably due to CPU usage being maxed out, but CPU usage ranges between 29% and 38%

By the way this only happens when I am using the Multiplexer Capelet. If I instead used MIDI inputs, I only start getting this error message when I have a lot of MIDI inputs routed around my patch (something like 60+). Right now I only have 8 Multiplexed analog inputs on channel 1 though.

Another note, the analog controls work fine except, one pot I am using for controlling oscillator frequency jumps noticeably in huge steps rather than in a smooth fashion. I'm not sure if the above problem is related to this.

Could this have something to do with how I made my PD patch? Are there inefficiencies I should avoid?

giuliomoro

abas I'd assume that this is probably due to CPU usage being maxed out, but CPU usage ranges between 29% and 38%

That's probably because you have something using CPU in bursts instead of spreading the load evenly across audio callbacks. Increasing the blocksize would work around that.

abas Another note, the analog controls work fine except, one pot I am using for controlling oscillator frequency jumps noticeably in huge steps rather than in a smooth fashion. I'm not sure if the above problem is related to this.

Wiring perhaps? Or it could be some artifact caused by the dropped blocks.

abas

giuliomoro Could you clarify how I would increase the blocksize ?

giuliomoro

in the project settings in the IDE there is a "Block size (audio frames)" parameter where you can set it. Then restart the program.

abas

giuliomoro Thank you!

This has all helped and my system is functional, increasing the block size has gotten rid of the dropped blocks message and smoothed out the controls as well. There is one peculiar behaviour that I noticed though:

It seems that the later multiplexed inputs have a much larger latency than the earlier ones. For example, I have 2 different inputs (0.1 and 0.7) which act like voice triggers. 0.1 is connected to a "Drone" switch. So that when its in a logical high position, voice 0 is droning. 0.7 is connected to a keyboard key so that when the user presses it, the voice is triggered on and when its off, the voice is silent.

The issue I noticed is that the drone switch is responsive (no noticeable latency) however, the keyboard key has a very high latency (something like half a second). When I switched their inputs around 0.1 to 0.7 and vice versa. The latency was experienced on the drone switch.

Is there anything I can do to fix this? I would imagine that all muxed inputs would have about the same amount of latency. The current design requires all 64 inputs with the muxer

giuliomoro

abas I would imagine that all muxed inputs would have about the same amount of latency

yes that's how they are meant to work.

What block size are you using? Can you try a simpler patch that only tests the latency but doesn't cause underruns at lower blocksizes and then go back to a blocksize of 64 and see if you still experiment the same issue? There could be something that breaks when switching from 64 to 128, but I don't think it would break quite in this way.

It's also possible that you may be using the wrong channel (e.g.: a neighbouring one to the one you are expected). When using a channel (A) that has nothing connected to it but is close to one that does (B), the signal read from channel A may look like a noisier, slower, more sluggish version of the signal plugged into channel B and this could manifest itself in a way similar to what you are describing,