Lots of inputs...what are my options ?

dadasane buttons (regular keyboard mechanical switches) require analog inputs

no, you would normally use digital inputs. However, you can use them with analog inputs, and just threshold them in the software.

what I mean is that you start by connecting the switch as usual:

3.3V
 |
 Z  R1 10k
 Z
 |
 |
 +----------------To Analog or digital Input
 /  switch
 |
Gnd

then if you connect it to the digital input, you will get only readings of 1 when it's not pressed and 0 when it's pressed. If instead you connect it to an analog input, you will read values around 0.8 when it's open and around 0 when it's closed. What I mean by thresholding is that you'd consider the reading a "digital 1" if it's above 0.5 and a "digital 0" if it's below 0.5. Something like:

analogValue = multiplexerAnalogRead(context, input, muxChannel);
digitalValue = analogValue > 0.5.

See, here and here for more info on the multiplexerAnalogRead() function

Does it make more sense now?

How many extra inputs do you need? There are 8 more available on BelaMini, though one is one the same pin as one LED (so it has limited range) and one is on the same pin as a digital I/O (so only one of the two functions can be enabled). Most of these have a strict 0V:1.8V range, and they are all slower to read than the Bela analogs, but it seems that they can work nicely in your case. If you only need 7 or 8 extra channels, these may work, but if you need more, you could look at building a little breakout board with a multiplexer on board which works similarly to the Multiplexer cape for the bigger Bela.

giuliomoro !!!OH that would be great!!! I only need 3 or 4 additional analog ins, so that sounds perfect! Could you specify how to access these inputs and whether they're available from Pure Data?

krzysztofcybulski Does the file "...in_voltage0_raw" have some extension? Just making sure I'm getting it right - the file gets automatically updated every now and then and holds a latest value of a given pin?

that's correct. It's a virtual text file (without a newline at the end). The value you read is a string containing values between 0 nad 4095. Every time you read it, it goes and takes a measurement of the ADC and returns that value. So it's not real-time safe at all. As it's a virtual file, it seems that Pd is having trouble to read it. We'll have to make a C++ workaround I guess.

giuliomoro
!!! Thanks a lot!!! I'll give it a try!

giuliomoro You must forgive me, but I'm totally dub when it comes to Linux, command line etc.
By "drop this file" you mean dropping it by using the Bela IDE? I've done it and the file is visible, yet, when I try to run the project on Bela, I get the following:

Makefile:483: recipe for target '/root/Bela/projects/test_czytania_pliku_analog_in_dodatkowe/build/render.o' failed

and:
'libraries/libpd/libpd.h' file not found column: 10, line: 33

Not sure how to deal with it.
Apologies again, cuz it's probably bread and butter for anyone familiar with Linux coding...

just update your Bela core code and try again. Instructions here: https://learn.bela.io/using-bela/bela-techniques/updating-bela/

giuliomoro Works great now, thank you! Your advice and commitment is priceless, as always!

giuliomoro Just a short postscript: I tested the solution (using the "hidden", original PocketBeagle analog inputs within Pure Data) and it works great - everything's ok and the readings are stable, the only thing that is less than satisfactory (altohough exactly just like you've described it) is the frequency of the readings - between 19 and 20 per second). I was just wondering if there is a possibility of a simple tradeoff - i.e. if I would only like to read 3 out of 8 inputs, would the readings be faster? Or it doesn't matter and it would be still the same frequency?

The reading loop in the code is:

	while(!Bela_stopRequested())
	{
		for(size_t n = 0; n < gLowResAnalogIn.size(); ++n)
		{
			path[x] = '0' + n; // int to char
			std::string ret = IoUtils::readTextFile(path);
			gLowResAnalogIn[n] = std::atoi(ret.c_str()) / 4096.f;
		}
		usleep(kLowResAnalogInSleepUs);
	}

and the kLowResAnalogInSleepUs constant is defined as:

static constexpr size_t kLowResAnalogInSleepUs = 50000;

which is what's driving your sampling period. Change it to, e.g.: 10000µs to get about 100Hz.