@timothyschoen I see, thanks for the explanation of the process, it makes sense.
Look forward to dive more into PlugData.

Truly awesome project @timothyschoen !
I installed the previous version last week and had an overall good experience with basic patches, with some minor issues that hopefully I find time to post to the tracker in github.

In any case, thanks so much for doing this! Among the previous attempts to make alternative GUIs for Pd, yours stands out.
I was almost moved when I run it on my laptop after using Pd for 20 years, this is something to behold eheheh

While for long-time users like me it may be tricky to completely switch from Pd-Vanilla to a new GUI, I think the kind of work you are doing will be very helpful to Pd in the long run, especially in helping beginners not to feel intimidated by the trademark, stern GUI of Pd and instead enjoy its community, potentials and quirks
And I can think of several use cases where a user who normally works in Pd-Vanilla would find useful to have the possibility to transfer patches to PlugData: like, creating easily readable patches and plugins for third party use, or artwork packages ready for exhibitions, etc... exciting.

I am curious about the strong resemblance to Max; is it something planned for a particular reason or it was merely used as a quick reference?
It would be even nicer to have a GUI that is unique to Pd, but that's just an aesthetic point lol Nothing to take away from your work!

hey @whale-av @manuels @jameslo thanks once again for the feedback! I think we are getting there, very exciting. I just quickly plugged your suggestion into my patches and they both work well. Interestingly enough now the sig~ and the resampling method result in two sounds that are timbrically quite different, but still coherent with what I would expect. This is super interesting, even as a creative toolset, as long as the difference in timbre are not artefacts. I will investigate this further and try to post some audio examples.

Gonna work more on the project this week and keep you posted. Just bear with me as I cannot work on this full-on every day like the past weekend, cause of other commitments.

@jameslo sorry to hear, it is quite jumping around these days, I hope your symptoms are bearable, and I'm glad that an interesting problem can help a little

@whale-av the vline~ there is very elegant! I had previously tried with a line3 in the control domain but your suggestions makes more sense. I've used a bucket object to get the interval, that should be the same as what you are doing in your patch.

@manuels yes, indeed. Different filters are the next thing I'm gonna look into, especially as I gonna need a more systematic spectral analysis of the resulting sound to make sure it is still coherent with the expected signal.

@jameslo I think you understood everything correctly! I think David and I were just trying to clarify the problem in that early post.

Hello, here's an update, this is where I am at:

Method #1 with sig~ and lop~ @whale-av

• this works now quite well now. A lop~ at 40 actually hits a sweet spot for the kind of sounds I need to pick up with the mic. Not sure why though. The resulting output is still a bit "noisy", but works well with my patches for the standard XTH Sense, where I use the same mic, but wired. So, this is very good.

Method #2 with tabread4~ @jameslo

• I didn't manage to make it work merely because I didn't understood it fully, not because of the method per se, which looks sound. I didn't put too much work on this, since method #3 seems to be an extension of this, so I focused on the latter.

Method #3 with tabread4~ and vline~ @manuels

• This works well in my patch above, but strangely enough the upsampled signal still presents the steep steps. The output signal sounds as the output from sig~ from method #1. So here I may have missed something in the implementation? or perhaps is the lack of timestamp...

Updates on other solutions we discussed:

• timestamp: I did manage to get a timestamp using the millis() function, which I think should be enough for this use case. This simply counts ms passed from the moment the board has been switched on and attaches it to each reading

• Increasing the sampling rate on the arduino rp2040 with the microcontroller of the same name seems pretty unexplored (at least after one day of investigation on forums etc..). I need to look more into it. But considering what David pointed out about the brickwall at 689Hz, maybe this is not even an option here.
• FYI, on ARM microcontrollers it is possible to use prescalers, bypass analogRead and read analog data directly from the hardware using register calls at quite fast rates (some people managed to almost 40.000). But I chose the rp2040 for its dimensions, its wifi connectivity (and, partially, for the onboard machine learning features). So if anyone knows of another off-the-shelf board that uses ARM and has similar dimensions and connectivity, please point it to me I'll check too of course.

Next steps:

• as it stands, method #1 works well with my patches too and I could just lay back and test this further with my performance software. Especially since by applying the audio signal conditioning and processing I have in my software, the difference with the wired signal is not seriously noticeable and the wireless is even more responsive and less prone to artifacts
• BUT! I would really like to get the upsampling work since it is potentially the most technically sound solution. So I would like now to work more on this using vline~ with the timestamp. A pointer in that direction would be great, since admittedly arrays and tabreads are one of my weak spot in Pd.

P.S. A clarification, before I stated 40Hz as the max. frequency I need to capture, but, to be precise, the range of muscle sounds (including heartbeat and blood flow) is between 1-25/30Hz, as you can see from this pic (a magnitude spectra of the output signal from lop~ capturing a forearm contraction)

Hey @whale-av @jameslo @manuels just dropping a note that all your suggestions are very interesting and I'm gonna work today on implementing and comparing them (got some mileage yesterday refining the patch with sig~ and lop~ with some decent results, next will try the tabread~ options).
I would like to do then a round up and post some results here, then see where to go from there.

and David, yes, I love and am grateful to see other people thinking with me in real time, that's the beauty of these kind of things

Thanks!
M

@whale-av aha, cool see it now

Thanks @whale-av David, several good pointers in your reply.

The sampling period is continuously updated. It's a basic method using fifo and timer. Do you perhaps have suggestions for a more precise measurement technique?

Yes, you are right, the clocking issue may be where to look into first. Incoming values are not regulated yet, I'll get down to do that now (was hoping to get a more or less stable sampling period from the arduino, probably naive.) And thanks for the link!

and now that I read you about tabwrite~ I see that I always understood it wrong Thanks.

to your P.S.: Yess, that sounds like one of the things I was missing. It could be. If this is the case, the patch is fine and the problem is the low sampling rate, then I can see two options:

• increase the sampling rate in the arduino. I found this tutorial that gets you, allegedly, at 38.5kHz sampling rate on analogIn
  or
• would it make sense to prepare the signal in a subpatch with a low sampling rate matching the arduino's and then in a parent do upsampling and interpolation before sending out to processing?

Ok, gonna work on it and come back with updates.
Marco

thanks @alexandros, yes, that's the first thing I tried, but I gets only noise, seeing the shape of the wave in an array it seems there's something wrong about either the sampling rate or the bit resolution...?

Hi all,

this feels like a trivial problem, but I can't get my head around it.
I've got an electret mic connected to the analogIn of an arduino rp2040 connect. I'm sending the analogIn values via WiFi over UDP as OSC. I get the data in Pd and I would like to "reconstitute" the mic sound from the analog reading.

I'm familiar with how ADC works, but either I'm stupid or there's something I'm missing and I can't figure out how to go about this in Pd.

Some details:

• the mic output goes through a breakoutboard amp, so the signal arriving into the arduino is already DC Offset and centered nicely between 0 and 1023
• the signal is handled in Pd with a sampling rate of 500hz (according to my measurement), which should be fine for the low frequency sound I'm producing into the mic (sounds won't be higher than 40Hz)
• why I don't simply use a wireless audio transmitter? it's a long story, but this relates to making my long-running XTH Sense biosensor wireless. In the past years I tried many different options to no avail (including making a startup and producing a custom wireless audio hardware), and I came to the conclusion that the project needs the simplest and more reliable ever implementations, if others are really to continue use it.

Any hint is greatly appreciated!
thank you,

M

Hey all! Just noticed the conversation went on. Strange I didn't receive a notification of the new messages.

Anyway, just saying I just upvoted the proposed implementation and expressed my view on the -path library scenario.
Hope it helps a little. I'll try to follow the convo on github.

Hey @seb-harmonik.ar @ingox thanks for the pointers.

Without wanting to take away anything from the fantastic latest developments of Pd, I find it a bit disheartening to find out that - after using Pd since 14 years - some basic usability flaws like these ones are still not addressed. It's not really a lot of effort or a drastic change.

@seb-harmonik-ar thanks, yes, I had set the path to zexy in my preferences. The objects would not created not only in my own patches bu also in their own help files. And with the same prefs path, my old zexy works fine, while the newly downloaded zexy from deken is broken. Not all objects are broken but many of them. I checked a few help file at random and 4/5 help files had broken objects.

Anyway, I did more testing and I'm a little baffled. It turns out that whether I add zexy to the path preferences or not is completely irrelevant. If I do it or not, zexy from deken doesn't work.

The lib works only when I include [declare -lib zexy -path zexy], as Seb suggested. Now, this doesn't really make sense from a user point of view: first, because this is not indicated anywhere, and second, because the declare object is not included in zexy's own help files. This means that when one uses the Pd Browser to open some zexy help files, most patches are broken because zexy itself doesn't get loaded by its own help files. Am I missing something here? This seems to me a weird approach, does anybody knows whether this is wanted by IOhannes (who I think is the maintainer)?

@oid Yes, that's exactly what I find confusing, and I agree with you that deken should follow conventions. That said, from a brief research on AMD64_32, it would seem that it refers to code compiled so as to run as 32-bit on a 64-bit system.
See for instance: https://www.oracle.com/database/technologies/instant-client/linux-amd64-downloads.html
https://wiki.gentoo.org/wiki/Project:AMD64/32-bit_Chroot_Guide

In any case, as per my message above the AMD64_32 version works, but only with [declare].
(and zexy versions from 2015 in deken are named AMD64_64, by the way).

mmmm....

ok, so I found time to compile Pd, 0.51.2, and I think now I understand my problem was twofold.

Pd compiles fine and all libraries in /extra works fine now.
So the fact that those same libraries installed by the public package were broken could point to issues with the package itself, as @oid suggested.

The other issue with the libraries installed via deken. Well, on one hand is my bad: those broken libraries I had installed were not technically broken, but simply compiled for AMD64_32 which is a different architecture than my machine (which is 64-bit). I had installed the 32-bit version without even checking what it was, I assumed the most recent deken package would be compiled for all platforms, but apparently this is not the case.

Which leads to my other question: I find it strange that those very common pd libs are not compiled for 64-bit platforms?

Anyway, issue is not entirely solved, but at least I understand now what has happened.

Hi @oid

ok, I see, that's what I wanted to know.

It would be good to know whether anyone else has installed the same package and is not having troubles, or else...

Yes, compiling is a good way to understand whether it is my system, thanks for the suggestion. That said, I have a fresh linux mint install, so it would be strange, but one never knows.

Not sure when I can do it since this is happening on my production/touring machine, that's why I was looking to know more about others' experiences. But I'll post info here if I discover anything relevant.

Thanks for now!

Hi all,
it has been a while, hope you are all doing well despite the times.

I'm on Linux Mint 20 on a DELL M4800. I installed pd with:

sudo apt install -y puredata

The available package is 0.50.2. I'm aware this is not the newest, but I would expect the package to be fully functional since it's available in public repos.

The problem is that Pd works fine but numerous libs are broken, i.e., objects cannot be created.
This affects both libraries that came with the puredata package I installed and libraries that I installed via deken.

I confirmed that, at least for the broken libs installed via deken, it was not a problem with [declare] or paths or startup prefs, because I replaced the broken libs with older versions of the same libs that I had in my archive, while keeping the same paths prefs. The older versions of the libs work.

The libraries installed via deken that are broken are so far:

• zexy
• timbreID
• maxlib
• iemlib
• iemgui
• creb

Other broken objects from /puredata/extra/ :

• bonk~
• sigmund~
• fiddle~

There may be more that I haven't noticed, these are the ones I use in my projects.

Am I doing anything wrong, or is there something wrong with this package, and if so, any idea what could it be?
I'm speculating it could be some objects are compiled for an incorrect architecture, or perhaps some issue with the libraries loader?

Thanks in advance for the help,
best wishes,