Hi @Lacuna thanks so much for these suggestions and the links.
Certainly, I am reading the data sheets and documentation.
However, I had missed the forum topic you posted and I will check this github.

I have been also using an old laptop with comport for a lot of projects in fact, comport is an old friend. I guess what I am trying to do, is get the most from these bits of technology rather than multiply them, and especially in a single project. I find myself using both raspberry pi AND arduino because I can manage the audio well on the pi (or well enough) and other stuff on arduino, but really I know the pins on the Pi can do that stuff too, so I just thought I would start to look for perspectives on how other people are doing these things.

I am going to explore your suggestion of doing the PWM in Pd and then sending this across the pins on the Bela to control things, I think this is the sort of very direct approach I was finding myself hazy about.
All the best,
Jorge

hello! this question intersects with Pd even if it is not about Pd specifically...
I currently have several (installation) pieces in which the sound is run from Pd and then I have motors or sensors being run off other things.
This means that in one case I am using a raspberry pi for the Pd part and an Arduino mega for the motor part
In another case I have Pd running on a Bela/BBB and then an Arduino doing the motor stuff.

The reason for this inefficiency is that my knowledge is fairly limited on these platforms. However, it is annoying to have to use the extra gear when I don't have to. Especially because I know that both the raspberry and the Bela have pins that could be used in place of the arduino for this purpose. Since the Bela is a simpler case and the pins can be addressed directly from Pure Data, I will ask about that and leave the Raspberry behind for now (as I think I would end up running Pd AND Arduino on that board anyway, whereas with Bela, one can easily address the pins from inside Pd without any other programs or libraries).

My question is this: does anyone know how the standard mappings of pins Analog/Digital/and PWM pins on the Arduino lines up on the Bela? Does the Bela have have PWM pins like, for example pins 8,9, 10,11 on Arduino Mega or Dueminanove? And if so, what is the best way to address them from Pure Data? Basically, I'd like to convert my already very simple Arduino sketches over to Pd, so that both motors and Audio can run from the same patch.

I know this isn't specifically a Pd issue but I have asked a related question on the Bela forum but didn't get an answer so I hoped someone might know or be able to suggest a resource over here...
I have traversed the Bela documentation already of course....and will continue with that meanwhile.

Jorge

In one of the classic pd books (but not Kreidler, Pucketter, nor Farnell I don't think) there is a great example in which three different approaches to making granular synthesis are given using three different ways of overlapping windowing functions.

Does anyone know where or what this book is?

I was trying to demonstrate something related to this the other day and I remembered these examples but can't for the life of me recall where I saw them.

yes, the OSC option is definitely a good one (though I wonder what a good program for this is on android...I have to check if 'control' does this...there is osculator on mac stuff but it is paid...in fact the libpd thread started just before this one (https://forum.pdpatchrepo.info/topic/13969/questions-about-using-lib-pd) is also helpful...

I am interested not so much in grabbing sensor data and sending it to pd on a computer but rather somehow using Pd directly on a mobile platform, and getting sensor data and particular gps data directly in there. There was also a post today on the Pd Forum about webpd being rebuilt, so that could help with that (you will be able to run vanilla Pd in a browser if that happens)

MobMuPlat grabs data from several of these sensors very well already...but you have to deal with the pd patch +java interface with that, and also the limitation of the 32-bit floating point numbers...so I am looking for other options. Especially because of the 32 bit floating point number issue as the GPS values that are interesting to me 6-7 digits long. Hopefully webpd will be 64 bit.

just wondered if anyone is using this?
https://github.com/deusanyjunior/Sensors2PD
It seems to suggest that you can run Pd patches off of an SD card on an Android phone...not sure which wrapper or what or how it works.
I have been using MobMuPlat but this seems like another nice way to get phone sensor data into a patch...maybe more easily even.

I wondered about setting up libpd using the PdCore module from that without too much coding. The program above requires that but not sure if it simply requires it to be installed or if you have to configure it through scripting somehow. This and actually compiling libpd has been a roadblock for me so far as I don't know what I am doing with that and get endless errors...

Any thoughts on this? Just curious if anyone is using it and if so how...

@bocanegra
super clear
thanks again!
J

So, I have it that the block size is the number of samples per block and that the numbers attached to each is the value of each sample in that block.

Then, I am looking at an FFT from which you can get a similar-looking array
and is it that the first value will be the lowest frequency and then each subsequent value is another frequency band, with the total number of bands being the block size
(so, if the blocks are set to 512, then there are 512 bands of analysis arranged low to high?)
How do you find out what the center of each of these frequency bands is (I mean without a gui, from the design side)
are each of these bands just equally divided (linear) values in hz based on the nyquist frequency or sampling rate (i.e. (44100/2)/512)
or is there some other logic to the spread of frequencies represented by the different bands?

@bocanegra
thank you! well explained!

if I make a simple patch like this:
[osc~ 220]
| [bang]
|
[print~]

I get an array of numbers for each bang in the console.
Can someone tell me what these numbers represent?

are they amplitudes of the signal at various time points in chronological order?
if I use [tabwrite~] to store them in an array in my patch instead of printing them to the console are the indices then in chronological order?

how does one get the frequency content of the signal back from this array of amplitude/time points?
I guess this is a question that is related to how FFTs work maybe...

I am giving away the fact that I am not a signal processing wizard here, but I would be very interested to know how these different numeric representations of these signals show their (the same?) information..
thanks!
J

Wow! Great. I hope to get a chance to try this out soooon!!!