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 everybody,

Sorry, for a lot of text. But the bold text at the bottom is my main question. The rest will help you to get a better understanding of my situation.

you helped me so much, with my last question here (the Faders are working dope now):
https://forum.pdpatchrepo.info/topic/13849/how-to-smoothe-out-arrays/25

I am doing a Steinberg Houston to Mackie Control emulation at the moment, to use my controller with other DAWs than Cubase/Nuendo. Will upload it to the internet community, when I am finished for the handful of people that maybe are also using this controller.

I made good progress:

I got the Faders and the normal knobs to work. And the display puts out information. But it is with bugs, because the LCD Screen of the Houston has 40 characters for one line and the Mackie Universal Pro has 56 Characters. So i did a list algorithm, which deletes spaces of the mackie message until the message fits on the 40 character line. Maybe there is a method wich will work better but this subject eats too much time for me at the moment and it works rough okay. One defenitely get's some helpful information on the screen from the DAW.

The Faders and Rotary Knobs and normal knobs are the most important of this controller I guess. The Faders are working fine as I mentioned above, but there is a problem with the rotary knobs, wich I can't handle alone and hope you can help me.

The problem is, that the Mackie Controller send simple clicks to the DAW. If you are turning a rotary knob, it sends out a number of midi messages:
If you turn it right, it sends midi messages wich contains the value 1 and if you turn it down it sends messages wich are containing the value 65.
"When the VPots are rotated rapidly, a message equal to the number of clicks is sent."

BUT the Houston controller instead is sending values like it's faders with 15 (MSB) and 128(LSB) values. AND it is updating the rotary limit by itself. So if I turn a rotary, it will update it's LEDs and stops sending midi messages when it reaches the maximum or minimum value. So, I did this patch as a momentary state:

Rotary Encoder Example.pd

The DAW sends 11 values for the Houston LEDs. 11 is max and 1 is min. This is good, I send this values to my houston controller and can update the rotary values and LEDs.
With this updated values from the DAW, I can force my rotary knobs, that they don't stop to send values, because they are set to the values, which the DAW sends, every time I turn a knob. With this method I got it to work to imitate a Mackie Rotary knob. Everytime the Houston Rotary value changes, it sends Mackie "midi click values" according to the amount of midi value changes of the houston.
BUT the problem is, that this is working only in one direction. Now my main question:

How can I make pure Data know, if I am turning my knob in the left direction or in the right direction? There is also the problem, which I mentioned above, that I set the momentary value everytime, I move the rotary, so that I get a unlimited amount of possible rotary move "clicks". Also the midi values which the houston sends arent perfect smooth. It works fine, but it isn't like that, that if you move a rotary in one direction, every value one by another is perfectly lower or higher.

I think I maybe need a algorythm, which looks if the values in a time period are getting higher or lower and then send out bangs on two seperate outlets. For example the left outlet for lower values and the right outlet for higher values. And it should also detect, if I move the rotary fast or slow. So a constant smoothing or clocked bang is also not an option. This is defenitely to complicated for me. I have no idea and what I tried didn't worked.

Would be super cool, if you could help me out again.

@ddw_music said:

I still think Tcl/Tk has failed to keep up with modern standards, and I have my doubts that it will ever catch up. So, I still think that Pd hampers its own progress by hitching itself to the Tcl/Tk wagon.

I think most people agree with you, myself included. Tk is clunky but it's in the current code base and has been kept so far since it works, although admittedly barely in many cases.

The last couple of posts here are encouraging.

I know development is slow, but it's really working against inertia. Momentum has been growing the last years and that's mostly due to more effective collaboration to tackle some of these issues. I think finding a sustainable approach to the GUI is one of the largest ones, so is taking a while to grow.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

Developer vs user perspective. The user sees clean diagonals on Mac, and jagged diagonals on Linux or Windows, and I think it's perfectly legitimate for the user not really to care that it's the OS rather than the drawing engine that makes it so in Mac. (It's correct, of course, to point out that the diagonals on a retina display will look smoother than antialiased diagonals without retina.)

Yup, you are totally right. I didn't mean to imply the Linux screenshot looked good since "that's the way it is" just more that it looks so much better on macOS since the screenshot is likely double the resolution as well.

I started using Pd on Windows circa 2006 then jumped to Linux for many years, then to macOS. My feeling was that Pd worked best on Linux but a lot of that has caught up as the underlying systems have developed but in some ways the Linux desktop has not (for many reasons, good and bad).

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

I did try Purr Data, but abandoned it because (at the time, two years ago), Purr Data on Mac didn't support Gem and there were no concrete plans to address that. This might have changed in the last couple of years (has it? -- I've looked at https://agraef.github.io/purr-data/ and https://github.com/agraef/purr-data but it seems not quite straightforward to determine whether Gem+Mac has been added or not).

That's a result of many of the forks adopting the "kitchen sink" monolithic distribution model inherited from Pd-extended. The user gets the environment and many external libraries all together in one download, but the developers have to integrate changes from upstream themselves and build for the various platforms. It's less overheard for the user but more for the developers, which is why integrating a frankly large and complicated external like GEM is harder.

I'm happy to download the deken GEM package because I know the IEM people have done all the craziness to build it (it's a small nightmare of autotools/makefiles due to the amount of plugins and configuration options). I am also very happy to not have to build it and provide it to other users but in exchange we ask people to do that extra step and use deken. I recognize that the whole usage of [declare] is still not as easy or straightforward for many beginners. There are some thoughts of improving it and feedback for people in the teaching environment has also pushed certain solutions (ie. Pd Documents folder, etc).

Tracking vanilla releases was the other issue. A couple of years ago, [soundfiler] in Purr Data was older and didn't provide the full set of sound file stats. That issue had been logged and I'm sure it's been updated since then. "Tracking" seemed to be manual, case-by-case.

By "tracking" I am referring to a fork following the new developments in Pd-vanilla and integrating the changes. This becomes harder if/when the forks deviate with internal changes to the source code, so merging some changes then has to be done "by hand" which slows things down and is one reason why a fork may release a new version but be perhaps 1 or two versions behind Pd vanilla's internal objects, ie. new [soundfiler] right outlet, [clone] object, new [file] object, etc.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years...

Well, I mean, OK up to a point. There are things like the Tcl/Tk open/save file dialog, which is truly abhorrent in Linux.

Hah yeah, I totally understand. My first contribution to Pd(-extended) was to find out how to disable showing hidden files in the open/save panels on Linux. You would open a dialog, it defaulted to $HOME, then you had to wade through 100 dot folders. Terrible! Who did this and why? Well it wasn't on purpose, it was just the default setting for panels on Tk, and I added a little but of Tcl to turn it off and show a "Show hidden files/folders" button below.

OTOH I have a colleague at work who's internal toolkit still uses Motif. Why? Well it still works and he's the only user so he's ok with it. I'd say that Tk also still uses Motif... but there are many users and they have much different expectations. ;P

Some puzzling decisions here and there -- for example, when you use the mouse to drag an object to another location, why does it then switch to edit the text in the object box? To me, this is a disruptive workflow -- you're moving an object, not editing the object, but suddenly (without warning) you're forcibly switched into editing the object, and it takes a clumsy action of clicking outside the object and dragging the mouse into the object to get back to positioning mode. I feel so strongly about it that I even put in a PR to change that behavior (https://github.com/pure-data/pure-data/pull/922), which has been open for a year and a half without being either merged or rejected (only argued against initially, and then stalled).

Ah yes, I forgot about this one. It wasn't rejected, just came at a time when there were lots of other things shouting much louder, ie. if this isn't fixed Pd is broken on $PLATFORM. I would say that, personally, your initial posting style turned me off but I recognize where the frustration came from. I also appreciate making the point AND providing a solution, so the ball is in our court for sure. I will take a look at this soon and try it out.

"Still working for 20 years" but you could also say, still clunky for 20 years, with inertia when somebody does actually try to fix something.

Another approach would be to try to bring improvements to Tcl/Tk itself but the dev community is a little opaque, more so than Pd. However I admit to not having put a ton of time into it, other than flagging our custom patches to the TK macOS guy on Github.

WRT to the rest, any architectural improvements (e.g. drawing abstractions so that the Pd core isn't so tightly coupled to Tcl/Tk) that make it more feasible to move forward are great, would love to see it.

As would I... we are preparing for a major exhibition opening in December, but I will have some time off after and I may take a stab at a technical demo for this (among other things) then pull in some other perspectives / testers. It has been an itch I have wanted to scratch since, at least Pd Con 2016 in NYC.

Howdy all,

I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.

I'm just writing for myself and don't speak for Miller or anyone else.

Mac looks good

The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.

There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."

In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.

This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.

Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.

tkpath exists, why not use it?

Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.

And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.

It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.

Why aren't the fonts all the same yet?!

I also despise how linux/windows has 'bold' for default

I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.

Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others?

And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.

Why don't we add abz, 123 to Pd? xyzzy already has it?!

What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.

Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

Yes, this is correct, but first we have to keep the damn thing working at all. I think most people agree with you, including me when I was teaching with Pd.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.

This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).

A couple of points:

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work.

A way forward: libpd?

I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."

For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."

So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).

Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.

Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.

Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...

Discouraging Initiative?!

But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.

We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.

At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.

This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.

That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.

Out

Ok, that was long and rambly and it's way past my bed time.

Good night all.

Hi folks! I've been getting to know Pd and having a ton of fun doing it, but I've run into a pickle that is turning the fun more towards frustration
As my first project, I decided to build a musical version of Conway's Game of Life, and I even got a small version of it working, but trying to make the game a bit larger has stalled on a weird issue that I just can't seem to solve.

Basically, my "game" is made up of cells, which are abstractions that are identical in every way, except they take as a creation argument a number, which determines both the order in which the cells are processed, and their position in the game grid. When the game grid is loaded up, a bang goes to cell number 1, which reads its own creation argument and calculates based on that, and the number of rows and columns in the grid, which cells are its neighbors. It then sends a bang to cell 2, which does the same and sends a bang to cell 3 etc.
"Playing" the game works similarly, with cell 1 first calculating how many neighbors it has alive, and then telling cell 2 to do the same etc. Once the last cell is reached, a new bang is sent to cell 1 telling it to set its new state, and this instruction is again passed forward to cell 2 etc.

This all works fine in a 5-by-5 grid. In fact, I've even been able to "play" some music using this smaller version (and it sounds pretty fantastic as well!). However, if I increase the number of rows and columns to 10, I get a "stack overflow" error when I load the grid up. Specifically, I've located the problem to cell number 56: it still has all its neighbors set up properly, but cell number 57 no longer does, implying that somehow cell 56 fails to send 57 the instruction to set up. This is quite strange considering that there is nothing different about cell number 56 compared to the previous cells, which have all worked fine.
I've checked that the creation arguments are correct, and the neighbors get set up correctly (though even if they didn't, the setup shouldn't cause a stack overflow). I can't think of an issue with the order of operations either, as the setup is handled cell-by-cell.

All ideas on what could be causing this would be be greatly appreciated! If anyone wants to dig deeper, here is a zip with the cell-abstraction and two versions of the grid-patch: one with 25 cells (this works), and another with 100 cells (this doesn't): game_of_life.zip
(I've taken out all the code having to with actually playing music with that thing so it's easier to understand, so it's just the visual part of the game, but it works standalone.)

I wanted to build PD on Windows 10 to get ASIO support. I failed when I used the "Source" files from the PD website. I succeeded when I used source that I cloned from Github. I followed the same instructions from the wiki both when I failed and when I succeeded. (They are the same as in the manual, just a little more concise.)

I am sharing below my terminal output from the failed build attempts from the downloaded source code (the tar.gz file). Some of these messages suggest that there might be errors in the makefiles. I don't know anything about makefiles, so I can't really interpret the errors. But I did want to pass them along, in case a developer might find them useful. Here you go:

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ./autogen.sh
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'm4/config'.
libtoolize: linking file 'm4/config/config.guess'
libtoolize: linking file 'm4/config/config.sub'
libtoolize: linking file 'm4/config/install-sh'
libtoolize: linking file 'm4/config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4/generated'.
libtoolize: linking file 'm4/generated/libtool.m4'
libtoolize: linking file 'm4/generated/ltoptions.m4'
libtoolize: linking file 'm4/generated/ltsugar.m4'
libtoolize: linking file 'm4/generated/ltversion.m4'
libtoolize: linking file 'm4/generated/lt~obsolete.m4'
configure.ac:166: warning: The macro `AC_LIBTOOL_DLOPEN' is obsolete.
configure.ac:166: You should run autoupdate.
aclocal.m4:8488: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:166: the top level
configure.ac:166: warning: AC_LIBTOOL_DLOPEN: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:166: put the 'dlopen' option into LT_INIT's first parameter.
../autoconf-2.71/lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:8488: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:166: the top level
configure.ac:167: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete.
configure.ac:167: You should run autoupdate.
aclocal.m4:8523: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:167: the top level
configure.ac:167: warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:167: put the 'win32-dll' option into LT_INIT's first parameter.
../autoconf-2.71/lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:8523: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:167: the top level
configure.ac:168: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:168: You should run autoupdate.
aclocal.m4:121: AC_PROG_LIBTOOL is expanded from...
configure.ac:168: the top level
configure.ac:182: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:182: You should run autoupdate.
../autoconf-2.71/lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:182: the top level
configure.ac:213: warning: The macro `AC_TYPE_SIGNAL' is obsolete.
configure.ac:213: You should run autoupdate.
../autoconf-2.71/lib/autoconf/types.m4:776: AC_TYPE_SIGNAL is expanded from...
configure.ac:213: the top level
configure.ac:235: warning: The macro `AC_CHECK_LIBM' is obsolete.
configure.ac:235: You should run autoupdate.
aclocal.m4:3879: AC_CHECK_LIBM is expanded from...
configure.ac:235: the top level
configure.ac:276: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:276: You should run autoupdate.
../autoconf-2.71/lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
m4/universal.m4:14: PD_CHECK_UNIVERSAL is expanded from...
configure.ac:276: the top level
configure.ac:168: installing 'm4/config/compile'
configure.ac:9: installing 'm4/config/missing'
asio/Makefile.am: installing 'm4/config/depcomp'

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ autoupdate
configure.ac:182: warning: The preprocessor macro `STDC_HEADERS' is obsolete.
  Except in unusual embedded environments, you can safely include all
  ISO C90 headers unconditionally.
configure.ac:213: warning: your code may safely assume C89 semantics that RETSIGTYPE is void.
Remove this warning and the `AC_CACHE_CHECK' when you adjust the code.

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ^C

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ./configure
configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
configure: iPhone SDK only available for arm-apple-darwin hosts, skipping tests
configure: Android SDK only available for arm-linux hosts, skipping tests
checking for as... as
checking for dlltool... dlltool
checking for objdump... objdump
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw64/bin/nm -B
checking the name lister (/mingw64/bin/nm -B) interface... BSD nm
checking whether ln -s works... no, using cp -pR
checking the maximum length of command line arguments... 8192
checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-mingw32 format... func_convert_file_msys_to_w32
checking how to convert x86_64-w64-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking for C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe option to reload object files... -r
checking for objdump... (cached) objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... (cached) dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /mingw64/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for vfork.h... no
checking for dlfcn.h... no
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether make sets $(MAKE)... (cached) yes
checking whether ln -s works... no, using cp -pR
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for windres... windres
checking for egrep... (cached) /usr/bin/grep -E
checking for fcntl.h... yes
checking for limits.h... yes
checking for malloc.h... yes
checking for netdb.h... no
checking for netinet/in.h... no
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for sys/ioctl.h... no
checking for sys/param.h... yes
checking for sys/socket.h... no
checking for sys/soundcard.h... no
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for unistd.h... (cached) yes
checking for int16_t... yes
checking for int32_t... yes
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for working alloca.h... no
checking for alloca... yes
checking for error_at_line... no
checking for fork... no
checking for vfork... no
checking for GNU libc compatible malloc... (cached) yes
checking for GNU libc compatible realloc... (cached) yes
checking return type of signal handlers... void
checking for dup2... yes
checking for floor... yes
checking for getcwd... yes
checking for gethostbyname... no
checking for gettimeofday... yes
checking for memmove... yes
checking for memset... yes
checking for pow... yes
checking for regcomp... no
checking for select... no
checking for socket... no
checking for sqrt... yes
checking for strchr... yes
checking for strerror... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for dlopen in -ldl... no
checking for cos in -lm... yes
checking for CoreAudio/CoreAudio.h... no
checking for pthread_create in -lpthread... yes
checking for msgfmt... yes
checking for sys/soundcard.h... (cached) no
checking for snd_pcm_info in -lasound... no
configure: Using included PortAudio
configure: Using included PortMidi
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating asio/Makefile
config.status: creating doc/Makefile
config.status: creating font/Makefile
config.status: creating mac/Makefile
config.status: creating man/Makefile
config.status: creating msw/Makefile
config.status: creating portaudio/Makefile
config.status: creating portmidi/Makefile
config.status: creating tcl/Makefile
config.status: creating tcl/pd-gui
config.status: creating po/Makefile
config.status: creating src/Makefile
config.status: creating extra/Makefile
config.status: creating extra/bob~/GNUmakefile
config.status: creating extra/bonk~/GNUmakefile
config.status: creating extra/choice/GNUmakefile
config.status: creating extra/fiddle~/GNUmakefile
config.status: creating extra/loop~/GNUmakefile
config.status: creating extra/lrshift~/GNUmakefile
config.status: creating extra/pd~/GNUmakefile
config.status: creating extra/pique/GNUmakefile
config.status: creating extra/sigmund~/GNUmakefile
config.status: creating extra/stdout/GNUmakefile
config.status: creating pd.pc
config.status: executing depfiles commands
config.status: executing libtool commands
configure:

    pd 0.51.4 is now configured

    Platform:             MinGW
    Debug build:          no
    Universal build:      no
    Localizations:        yes
    Source directory:     .
    Installation prefix:  /mingw64

    Compiler:             gcc
    CPPFLAGS:
    CFLAGS:               -g -O2 -ffast-math -funroll-loops -fomit-frame-pointer -O3
    LDFLAGS:
    INCLUDES:
    LIBS:                 -lpthread

    External extension:   dll
    External CFLAGS:      -mms-bitfields
    External LDFLAGS:     -s -Wl,--enable-auto-import -no-undefined -lpd

    fftw:                 no
    wish(tcl/tk):         wish85.exe
    audio APIs:           PortAudio ASIO MMIO
    midi APIs:            PortMidi


bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/c/Useras/bhage/Downloads/pd-0.51-4/m4/config/missing' aclocal-1.16 -I m4/generated -I m4
configure.ac:170: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro
configure.ac:170: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: autom4te failed with exit status: 1
make: *** [Makefile:451: aclocal.m4] Error 1

bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ make app
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/c/Users/bhage/Downloads/pd-0.51-4/m4/config/missing' aclocal-1.16 -I m4/generated -I m4
configure.ac:170: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro
configure.ac:170: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: autom4te failed with exit status: 1
make: *** [Makefile:451: aclocal.m4] Error 1

@oid said:

I am referring to it being made up from multiple objects instead of just one, analogy between transistors and integrated circuits.

Ok well, I was refering to the inherent phase shift that any digital filter has because of the discrete time and delay. No biggie.

Probably not control vs signal domain since they both have [mtof] on the cutoff so should be set to the exact same frequency. I am not talking about cancellation during the morph, as I said some transitions don't work, a resonance morph from 24db hp to 12db lp works but 24db hp to 18db lp results in the resonance results in the wrong phase after the morph, but a morph from 12db lp to 18db lp works just fine (don't recall if those actual transitions are the troublesome ones, just a random example). I suspect an error that can only be seen on the text level, order of operations (don't see anywhere this could be the issue) or an actual error which can not be seen in the patcher like the duplicate patch cable bug. I am fairly certain this just recently cropped up and the non-[lop~] filters did work but that might have just been an illusion caused by the mysterious 10 sample delay which had cropped up some how, I have no idea, hence starting over from scratch come weekend.

For resonance to work, there has to be a full 360 degree shift of the cut-off frequency while the other frequencies get cancelled/phased out. This works when you have 4 1 pole filters doing 45 degrees shift on the cutoff frequency each and then do negative (180 degree shift) feedback. But when you start mixing the different poles for the feedback you get all sorts of different phase distortions that wont create the magic self oscillation we love so much. Maybe try using the [filter-graph] abstractions from H10.measurement.pd to measure phase distortion on your resonance pole-mix and see what is going on.

As an aside, know of any suitable externals which is essentially [lop~] with signal rate? I looked some but only found more complex filters, would be nice to have that CPU savings which [lop~] provides but keep signal rate inputs. Or is the CPU difference primarily the signal rate cutoff? Seems too great to be just that.

I just ran a test on [rpole~] vs [lop~] (seppareately!)

Setting [rpole~] up like here, it works 'exactly* like [lop~]. They both spike at 30 CPU but stay at 20 most of the time. I think [rpole~] is as cheap as it gets with signal rate cut-off control. Of course, small differences add up when you have several instances.

I FINALLY made it work, it's now as reliable and foolproof as i can patch it!

midisettingsperpatch.pd

audiosettingsperpatch.pd

I spent quite some time to make it clean and well working, so i'm not sure it will save me time in the end, but i'm sure it can save you some, so please use it! Bear in mind you HAVE to modify it to contain your own audio and midi devices. Their names can be found using audiosettings and midisettings objects.

Each patch containing this one, if correctly modified, will create and send to pd the correct message to tell it to put which device on which "slot" of the audio and midi settings menus.

I also made a patch for audiosettings, which sets the audio interface of your choice, with all the appropriate settings, plus another "plan B" setting in case the main audio interface is missing.

Once properly set up, you only have to worry about plugging your audio and midi devices before launching Pd. What a relief in terms of time and stress, especially in live situations!

Sadly it needs Loopmidi or something similar to work, with as much virtual midi devices as the real ones you'll be using: if one or several devices are missing, the virtual ones will replace them in the midi settings, so it doesn't ruin the order of devices. I named them DUMMYIN\ 1 and DUMMYOUT\ 1 to 5 because i don't have more than 5 midi devices plugged at once. you have to create these DUMMY things in loopmidi to get this patch to work.

(I tried with one dummy midi device in and one dummy out, but it doesn't work if two real midi devices are missing in a row: pd apparently won't let you have twice the same device on consecutive slots)

the next steps would be to make it more user friendly, by sending messages to it, so it can be used in several different projects without being edited inside.

The most convenient solution would be to modify Pd source code to make these settings behave differently, by assigning a UNIQUE number to each device, being plugged or not, or accepting messages that contain the order of devices BY THEIR NAME and not a randomly assigned number... then it would be possible to store a simple midi and audiosettings message in each patch.

Thx for reading

#proudofmyself #nobodycaresaboutthisbutyouwhoareherebecauseofthesamepreoblem

@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....

Hello,

this is going to be a long one.
After years of using PD, I am still confused about its' timing and schedueling.

I have collected many snippets from here and there about this topic,
-wich all together are really confusing to me.

*I think it is very important to understand how timing works in detail for low-level programming … *

(For example the number of heavy jittering sequencers in hard and software make me wonder what sequencers are made actually for ? lol )

This is a collection of my findings regarding this topic, a bit messy and with confused questions.

I hope we can shed some light on this.

---

• a)
  The first time, I had issues with the PD-scheduler vs. how I thought my patch should work is described here:
  https://forum.pdpatchrepo.info/topic/11615/bang-bug-when-block-1-1-1-bang-on-every-sample

The answers where:

„
[...] it's just that messages actually only process every 64 samples at the least. You can get a bang every sample with [metro 1 1 samp] but it should be noted that most pd message objects only interact with each other at 64-sample boundaries, there are some that use the elapsed logical time to get times in between though (like vsnapshot~)
also this seems like a very inefficient way to do per-sample processing..
https://github.com/sebshader/shadylib http://www.openprocessing.org/user/29118
seb-harmonik.ar posted about a year ago , last edited by seb-harmonik.ar about a year ago 
• 1 
 whale-av 
@lacuna An excellent simple explanation from @seb-harmonik.ar.
Chapter 2.5 onwards for more info....... http://puredata.info/docs/manuals/pd/x2.htm
David.
“

There is written: http://puredata.info/docs/manuals/pd/x2.htm

„2.5. scheduling 
Pd uses 64-bit floating point numbers to represent time, providing sample accuracy and essentially never overflowing. Time appears to the user in milliseconds. 
2.5.1. audio and messages 
Audio and message processing are interleaved in Pd. Audio processing is scheduled every 64 samples at Pd's sample rate; at 44100 Hz. this gives a period of 1.45 milliseconds. You may turn DSP computation on and off by sending the "pd" object the messages "dsp 1" and "dsp 0." 
In the intervals between, delays might time out or external conditions might arise (incoming MIDI, mouse clicks, or whatnot). These may cause a cascade of depth-first message passing; each such message cascade is completely run out before the next message or DSP tick is computed. Messages are never passed to objects during a DSP tick; the ticks are atomic and parameter changes sent to different objects in any given message cascade take effect simultaneously. 
In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time. 
2.5.2. computation load 
The Pd scheduler maintains a (user-specified) lead on its computations; that is, it tries to keep ahead of real time by a small amount in order to be able to absorb unpredictable, momentary increases in computation time. This is specified using the "audiobuffer" or "frags" command line flags (see getting Pd to run ). 
If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On the other hand, disk strewaming objects will work correctly, so that you may use Pd as a batch program with soundfile input and/or output. The "-nogui" and "-send" startup flags are provided to aid in doing this. 
Pd's "realtime" computations compete for CPU time with its own GUI, which runs as a separate process. A flow control mechanism will be provided someday to prevent this from causing trouble, but it is in any case wise to avoid having too much drawing going on while Pd is trying to make sound. If a subwindow is closed, Pd suspends sending the GUI update messages for it; but not so for miniaturized windows as of version 0.32. You should really close them when you aren't using them. 
2.5.3. determinism 
All message cascades that are scheduled (via "delay" and its relatives) to happen before a given audio tick will happen as scheduled regardless of whether Pd as a whole is running on time; in other words, calculation is never reordered for any real-time considerations. This is done in order to make Pd's operation deterministic. 
If a message cascade is started by an external event, a time tag is given it. These time tags are guaranteed to be consistent with the times at which timeouts are scheduled and DSP ticks are computed; i.e., time never decreases. (However, either Pd or a hardware driver may lie about the physical time an input arrives; this depends on the operating system.) "Timer" objects which meaure time intervals measure them in terms of the logical time stamps of the message cascades, so that timing a "delay" object always gives exactly the theoretical value. (There is, however, a "realtime" object that measures real time, with nondeterministic results.) 
If two message cascades are scheduled for the same logical time, they are carried out in the order they were scheduled. 
“ 

[block~ smaller then 64] doesn't change the interval of message-control-domain-calculation?,
Only the size of the audio-samples calculated at once is decreased?
Is this the reason [block~] should always be … 128 64 32 16 8 4 2 1, nothing inbetween, because else it would mess with the calculation every 64 samples?
How do I know which messages are handeled inbetween smaller blocksizes the 64 and which are not?

How does [vline~] execute?
Does it calculate between sample 64 and 65 a ramp of samples with a delay beforehand, calculated in samples, too - running like a "stupid array" in audio-rate?

While sample 1-64 are running, PD does audio only?

[metro 1 1 samp]  

How could I have known that? The helpfile doesn't mention this. EDIT: yes, it does.
(Offtopic: actually the whole forum is full of pd-vocabular-questions)
How is this calculation being done?
But you can „use“ the metro counts every 64 samples only, don't you?

Is the timing of [metro] exact? Will the milliseconds dialed in be on point or jittering with the 64 samples interval?
Even if it is exact the upcoming calculation will happen in that 64 sample frame!?

---

• b )
  
  There are [phasor~], [vphasor~] and [vphasor2~] … and [vsamphold~]
  https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors

“Ive been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share. 
[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)
[…]
“

---

• c)
  
  Later I discovered that PD has jittery Midi because it doesn't handle Midi at a higher priority then everything else (GUI, OSC, message-domain ect.)

EDIT:
Tryed roundtrip-midi-messages with -nogui flag:
still some jitter.
Didn't try -nosleep flag yet (see below)

---

• d)
  
  So I looked into the sources of PD:

scheduler with m_mainloop()
https://github.com/pure-data/pure-data/blob/master/src/m_sched.c

And found this paper

Scheduler explained (in German): 

https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

wich explains the interleaving of control and audio domain as in the text of @seb-harmonik.ar with some drawings
plus the distinction between the two (control vs audio / realtime vs logical time / xruns vs burst batch processing).
And the "timestamping objects" listed below.

And the mainloop:

Loop
- messages (var.duration)
- dsp (rel.const.duration)
- sleep

With
[block~ 1 1 1]
calculations in the control-domain are done between every sample? But there is still a 64 sample interval somehow?
Why is [block~ 1 1 1] more expensive? The amount of data is the same!? Is this the overhead which makes the difference? Calling up operations ect.?

---

Timing-relevant objects
from iemlib:

[...]
iem_blocksize~   blocksize of a window in samples
iem_samplerate~  samplerate of a window in Hertz 


------------------ t3~ - time-tagged-trigger --------------------
-- inputmessages allow a sample-accurate access to signalshape --
t3_sig~          time tagged trigger sig~
t3_line~         time tagged trigger line~


--------------- t3 - time-tagged-trigger  ---------------------
----------- a time-tag is prepended to each message -----------
----- so these objects allow a sample-accurate access to ------
---------- the signal-objects t3_sig~ and t3_line~ ------------
t3_bpe           time tagged trigger break point envelope
t3_delay         time tagged trigger delay
t3_metro         time tagged trigger metronom
t3_timer         time tagged trigger timer

[...]

What are different use-cases of [line~] [vline~] and [t3_line~]?
And of [phasor~] [vphasor~] and [vphasor2~]?

When should I use [block~ 1 1 1] and when shouldn't I?

[line~] starts at block boundaries defined with [block~] and ends in exact timing?
[vline~] starts the line within the block?
and [t3_line~]???? Are they some kind of interrupt? Shortcutting within sheduling???

---

• c) again)
  

https://forum.pdpatchrepo.info/topic/1114/smooth-midi-clock-jitter/2

I read this in the html help for Pd: 
„
MIDI and sleepgrain
In Linux, if you ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00 (or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device number 0 is the "MIDI mapper", which is the default MIDI device you selected from the control panel; counting from one, the device numbers are card numbers as listed by "pd -listdev."
The "sleepgrain" controls how long (in milliseconds) Pd sleeps between periods of computation. This is normally the audio buffer divided by 4, but no less than 0.1 and no more than 5. On most OSes, ingoing and outgoing MIDI is quantized to this value, so if you care about MIDI timing, reduce this to 1 or less.
„

Why is there the „sleep-time“ of PD? For energy-saving??????
This seems to slow down the whole process-chain?

Can I control this with a startup flag or from withing PD? Or only in the sources?

There is a startup-flag for loading a different scheduler, wich is not documented how to use.

---

• e)
  
  [pd~] helpfile says:

ATTENTION: DSP must be running in this process for the sub-process to run. This is because its clock is slaved to audio I/O it gets from us!

Doesn't [pd~] work within a Camomile plugin!?

How are things scheduled in Camomile? How is the communication with the DAW handled?

---

• f)
  
  and slightly off-topic:
  There is a batch mode:
  https://forum.pdpatchrepo.info/topic/11776/sigmund-fiddle-or-helmholtz-faster-than-realtime/9

---

EDIT:

• g)
  I didn't look into it, but there is:
  https://grrrr.org/research/software/

clk – Syncable clocking objects for Pure Data and Max
This library implements a number of objects for highly precise and persistently stable timing, e.g. for the control of long-lasting sound installations or other complex time-related processes.

---

Sorry for the mess!
Could you please help me to sort things a bit? Mabye some real-world examples would help, too.