Well, from the help patch of [atan2] in Extended we have this in [pd atan2_vs_atan]....

To the best of my knowledge, this is just wrong and I did mention I saw many wrong things in the extended docs, well, hey, this is one number results simply do not match..., it's good "they" simply did not adopt this

also, to make it clearer, docs usually reffered to other externals, not part of vanilla, and they all came with this [pddplink] external object, so it wasn't possible to just take it... there had to be some work involved and I also wonder why "they who did the changes and made a parallel pd-extended documentation" did not try to actually collaborate to the Vanilla docs...

The pd extended docs do mention "them".... and I quote

"HELP_PATCH_AUTHORS This help patch was updated for Pd version 0.35 test 28 by Dave Sabine as part of a project called pddp proposed by Krzysztof Czaja to build comprehensive documentation for Pd. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42."

Again, I was no part of "pddp" and the "pddp" thing got revived, brought back to life and now I do focus on it and work on it a lot, but it's something for Vanilla now, really.

thank you, @timothyschoen ! unfortnately this did not work.
after commenting out the parts from your post i still got an error related to [pdlink~]

[ 25%] Built target parabolic_tilde
[ 25%] Building C object CMakeFiles/pdlink_tilde.dir/Source/Audio/pdlink~.c.o
In file included from /home/gregor/pd-else-v.1.0-rc12/Source/Audio/pdlink~.c:9:
/home/gregor/pd-else-v.1.0-rc12/Source/Shared/opus_compression.h:1:10: fatal error: opus.h: No such file or directory
    1 | #include <opus.h>
      |          ^~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/pdlink_tilde.dir/build.make:76: CMakeFiles/pdlink_tilde.dir/Source/Audio/pdlink~.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:3596: CMakeFiles/pdlink_tilde.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

I tried to just move the pdlink~.c file out of the source folder but then got errors for [pdlink]

[ 59%] Built target panic
[ 59%] Building C object CMakeFiles/pdlink.dir/Source/Control/pdlink.c.o
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:20:5: error: unknown type name ‘t_link_handle’
   20 |     t_link_handle x_link;
      |     ^~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_anything’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:45:5: warning: implicit declaration of function ‘link_send’ [-Wimplicit-function-declaration]
   45 |     link_send(x->x_link, (size_t)len, buf);
      |     ^~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_receive_loop’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:79:9: warning: implicit declaration of function ‘link_discover’ [-Wimplicit-function-declaration]
   79 |         link_discover(x->x_link);
      |         ^~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:81:25: warning: implicit declaration of function ‘link_get_num_peers’ [-Wimplicit-function-declaration]
   81 |         int num_peers = link_get_num_peers(x->x_link);
      |                         ^~~~~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:84:13: error: unknown type name ‘t_link_discovery_data’
   84 |             t_link_discovery_data data = link_get_discovered_peer_data(x->x_link, i);
      |             ^~~~~~~~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:84:42: warning: implicit declaration of function ‘link_get_discovered_peer_data’ [-Wimplicit-function-declaration]
   84 |             t_link_discovery_data data = link_get_discovered_peer_data(x->x_link, i);
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:85:27: error: request for member ‘sndrcv’ in something not a structure or union
   85 |             if(strcmp(data.sndrcv, x->x_name->s_name) == 0) {
      |                           ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:87:45: error: request for member ‘ip’ in something not a structure or union
   87 |                 if(x->x_local && strcmp(data.ip, "127.0.0.1") != 0) continue;
      |                                             ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:88:46: error: request for member ‘ip’ in something not a structure or union
   88 |                 if(!x->x_local && strcmp(data.ip, "127.0.0.1") == 0) continue;
      |                                              ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:90:31: warning: implicit declaration of function ‘link_connect’ [-Wimplicit-function-declaration]
   90 |                 int created = link_connect(x->x_link, data.port, data.ip);
      |                               ^~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:90:59: error: request for member ‘port’ in something not a structure or union
   90 |                 int created = link_connect(x->x_link, data.port, data.ip);
      |                                                           ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:90:70: error: request for member ‘ip’ in something not a structure or union
   90 |                 int created = link_connect(x->x_link, data.port, data.ip);
      |                                                                      ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:71: error: request for member ‘hostname’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                       ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:86: error: request for member ‘ip’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                                      ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:95: error: request for member ‘port’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                                               ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:93:106: error: request for member ‘platform’ in something not a structure or union
   93 |                    post("[pdlink]: connected to:\n%s\n%s:%i\n%s", data.hostname, data.ip, data.port, data.platform);
      |                                                                                                          ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:96:20: error: request for member ‘hostname’ in something not a structure or union
   96 |             if(data.hostname) free(data.hostname);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:96:40: error: request for member ‘hostname’ in something not a structure or union
   96 |             if(data.hostname) free(data.hostname);
      |                                        ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:97:20: error: request for member ‘sndrcv’ in something not a structure or union
   97 |             if(data.sndrcv) free(data.sndrcv);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:97:38: error: request for member ‘sndrcv’ in something not a structure or union
   97 |             if(data.sndrcv) free(data.sndrcv);
      |                                      ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:98:20: error: request for member ‘platform’ in something not a structure or union
   98 |             if(data.platform) free(data.platform);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:98:40: error: request for member ‘platform’ in something not a structure or union
   98 |             if(data.platform) free(data.platform);
      |                                        ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:99:20: error: request for member ‘ip’ in something not a structure or union
   99 |             if(data.ip) free(data.ip);
      |                    ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:99:34: error: request for member ‘ip’ in something not a structure or union
   99 |             if(data.ip) free(data.ip);
      |                                  ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:103:9: warning: implicit declaration of function ‘link_ping’ [-Wimplicit-function-declaration]
  103 |         link_ping(x->x_link, x, pdlink_connection_lost);
      |         ^~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:106:5: warning: implicit declaration of function ‘link_receive’; did you mean ‘pdlink_receive’? [-Wimplicit-function-declaration]
  106 |     link_receive(x->x_link, x, pdlink_receive);
      |     ^~~~~~~~~~~~
      |     pdlink_receive
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_free’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:113:19: warning: implicit declaration of function ‘link_free’; did you mean ‘pdlink_free’? [-Wimplicit-function-declaration]
  113 |     if(x->x_link) link_free(x->x_link);
      |                   ^~~~~~~~~
      |                   pdlink_free
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_set’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:151:17: warning: implicit declaration of function ‘link_init’ [-Wimplicit-function-declaration]
  151 |     x->x_link = link_init(x->x_name->s_name, pd_platform, x->x_local, 7680412);
      |                 ^~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:155:19: warning: assignment to ‘int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
  155 |         x->x_link = NULL; // TODO: handle this state!
      |                   ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c: In function ‘pdlink_new’:
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:163:15: warning: assignment to ‘int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
  163 |     x->x_link = NULL;
      |               ^
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:200:42: warning: implicit declaration of function ‘link_get_own_ip’ [-Wimplicit-function-declaration]
  200 |         post("[pdlink]: own IP:\n%s:%i", link_get_own_ip(x->x_link), link_get_own_port(x->x_link));
      |                                          ^~~~~~~~~~~~~~~
/home/gregor/pd-else-v.1.0-rc12/Source/Control/pdlink.c:200:70: warning: implicit declaration of function ‘link_get_own_port’ [-Wimplicit-function-declaration]
  200 |         post("[pdlink]: own IP:\n%s:%i", link_get_own_ip(x->x_link), link_get_own_port(x->x_link));
      |                                                                      ^~~~~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/pdlink.dir/build.make:76: CMakeFiles/pdlink.dir/Source/Control/pdlink.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:7756: CMakeFiles/pdlink.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

i hope this helps to make it work

@whale-av said:

But there is still a limit...... 198 is it...... in 32-bit extended

How? ...

Vanilla 0.53 will not show a result for either with input > 34...... a big for extended.and for vanilla.

The largest possible exponent in 32-bit float is 38. With an input of 34, you're already reaching this limit. Anything above that will be an incorrect result, so I'd say to extended for providing a false answer and no indication that the result is false. (Unless you meant 64-bit extended... but the exponent limit in 64-bit floats is 308, and 198! = 1.9815524305E370, also outside the limit... so even in 64 bits, 198! is a garbage result.)

hjh

@Muology No idea how efficient it is...... but it "works"...... factorial.pd
But there is still a limit...... 198 is it...... in 32-bit extended
If an external exists that will be more efficient.
And [expr] is probably more efficient than my patch, but its limit is 33..... in extended.
Vanilla 0.53 will not show a result for either with input > 34...... a big for extended.and for vanilla.
Most maths functions are built into [expr]........ and fact() is among them........
To see them all open Pd/doc/8.topics/expr.html in your Pd folder....
David.

@fina said:

I'm especially worried about multi mapping the controls to different pages/layers and how the controllers behave if the pot/encoder is in a different position

This can be a pain, faders (unless they are motorized) will jump, if you are at midi value 10 and switch too a different mapping that has that fader at max, when you move it it will jump down to 10, quite annoying but can be exploited and was a common trick on the early synths with patch memory that used analog controls, but this was generally more a hindrance than a help. Most modern controllers use endless rotary encoders which will update their values, in absolute mode you map out the controls on the controller itself and make presets, switch the mapping and the new values are there so no jump when you turn the knob but this has the disadvantage that they generally are limited to the low resolution 0-127 midi values. In relative mode the encoder sends only a plus or minus value so you can have unlimited resolution but you need to do more in pd since you need to add or subtract those plus or minus values from a stored value.

Personally I find mapping controls on a controller to be slow and I do need greater resolution so I do it all the mapping and the like in pd with relative mode, I made some abstractions to take care of all the work and they do some useful things like the first tick is ignored and just highlights the parameter being edited so when you forget what knob does what you can find your way without altering anything that is going on. This also means you are not limited by the controllers memory for mappings, I just do that in the patch so I have a virtually unlimited number of mappings. I use an Arturia Beatstep as a controller, 16 pads and 16 encoders, so each pad selects a mapping giving me 256 parameters I can edit or if I somehow needed more I could arrange the pads as 8 banks of 8 and 1024, but I have yet to need to do that. It also has the sequencer mode which is very limited but handy as an easy way to easily test sounds out. I can upload these abstractions if you decide on going with relative encoders, been on my list to get those uploaded but I tend to drag my feet on documentation so they have yet to get a proper upload, they have been uploaded a few times in various threads just not everything with actual documentation.

One thing to keep in mind, some controllers have software editors to make it easier to map stuff out, these software editors often do not work in linux even in Wine, so if you use linux you will want to make sure that the sysex commands have been published either by the maker or by someone who has sat down and figured them all out. For what ever reason some companies just will not release the sysex (Arturia being one of them). It is not terribly difficult to figure out the sysex on your own, just time consuming.

Hey there! I'm trying to find a good and versatile midi controller for pd in general, to get more tactile and hands-on controls for different patches. While researching I stumbled upon lots of different controllers in different price ranges, starting with fader/pot controllers like the korg nanokontrol or novation launchcontrol (xl), midi keyboards like the arturia keylab/minilab and akai mpk (mini), or endless encoders like behringer x-touch (mini), faderfox uc4/ec4, or the intech grid controllers.
I'm always struggling with decisions and therefore thought about asking for your experiences. I'm especially worried about multi mapping the controls to different pages/layers and how the controllers behave if the pot/encoder is in a different position. so if you'd like to talk a bit about your experiences with midi controllers, what works best for you, what you think is important to consider, and how you implement midi controllers in your patches and/or performances, I'd be very thankful!
Kind regards, f.

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.

@whale-av said:

@Bangflip Maybe you have seen this discussion...... https://discuss.cakewalk.com/index.php?/topic/19846-mackie-control-questions/

The Mackie control is supposed to spit out a direct linear midi slope...... Mackie Control Midi Table.pdf and only clockwise/counterclockwise and count for rotary encoders (like the BCF2000).

In the discussion above "skavan" has given an approximate formula for a linearization of the Cakewalk curve. Maybe there is other information out there or a question on a Cubase forum would shed some light.
Or maybe the curve is the same in Cubase as a lot of the software developers were moving around as Cakewalk folded.

Hey, thank you for the discussion link!

Also for the Mackie Control Midi Table. This link, I already knew, and is very helpful.

If you have jitter in the slope then make absolutely sure that you have no midi feedback anywhere in your setup....... I am a bit embarrassed to mention that as it seems you know what you are doing......
David.

I already made sure, that there isn’t any feedback. I also think it has maybe something to do with my configuration or the values, Cubase sends out, because the little midi drops are always the same with continuus raising of the Cubase Fader.

I am experienced with sound design, yes, but I am more a creative, not a technican or programmer. It‘s a project, to invest some time and learn pure data for me.

I am thankful for every tip.

@lacuna said:

Hard to tell without more details. I also have no experience with motorfader-hacks, but am interested.
At a precision of 1600 values it is very likely some subtle hardware bouncing, resonance of motor, dirt or similar ?
How slow do you drive them?
I would maybe try to eleminate the discontinuity on the hardware / measurement side, instead of cheating.
Do several measurements, instead of one shot only.
Also try to drive it from Pd instead of Cubase. Very slowly. Calibrating. Remember, there is some latency, too.

Anyway, this is what you where asking for, I think:
new romantics )

align_up_down_3c.pd

@lacuna Hey, thank you very much, for your help and the patch!

I will now describe more precisely, what I would like to do. I thought, it would be a little bit off topic, because it is a bigger project.

Also, I think, I described it not correctly with the motorfader recording. That isn't true. My english is not the best, so my formulations arent always on point, but I will try my best.

So, to describe my Project, I am working on:

I have an old 20 years old "Steinberg Houston" Midi-Controller, which works via the Mackie Protocoll. It was specifically designed as a Cubase / Nuendo Controller back in the days. Cubase / Nuendo are also, as far as I know, the only DAWs with which the controller is working nowadays.

Almost all DAWs are supporting the specifications of a "Mackie Universal Pro" Controller. So I would like to program a Midi-Data Converter, so I can use my controller with other DAWs as a "Mackie Universal Pro" Controller.

At the moment I already found out, which midi Data the faders send and which midi data the DAW Cubase sends to the Controller. I also converted the Midi Data, so that I can use the controller faders, while Cubase thinks, it is a Mackie Universal Pro.

So, but the problem, why I started this thread is, that I noticed, that the Mackie Controller needs to get different values from the DAW to get the right fadermovement done, than my Steinberg Houston. For example: When I set my Fader in the DAW to 6 dBFS, my Conroller Fader moves correctly to 6 dBFS, as that is the highest fader value in Cubase. Also the other way around. If I set the Fader in Cubase to -00 dBFS, also my Fader of the controller is at the right position. So the lowest and highest values are correct. But if I set -20 dBFS in Cubase via Mackie UP Mode, my controller sets the fader to -10 dBFS. In the original Cubase "Steinberg Houston" mode, the fader movements are very precise and always are reflecting the number, which I set in the mixer in Cubase.

So my Idea was, to first send all Pitchbend values from Pure Data via Midi to Cubase in Houston Mode. I tricked Cubase in thinking, I would use the Houston Controller, but used Pure Data instead, to be very precise. Then in the preferences of cubase, I deleted all automation smoothing and set up a tempo in Cubase and with Metro in Pure Data, so that each 8th note, one pitch bend value is send to Cubase. and I synchronised both my DAW Cubase and Pure Data with a C3, sent from Cubase, when I start the Playback in Cubase. This C3 is then sent to Pure Data and than acts as a bang in PD to start the metro and sends the Midi Values. This midi Values are written then in Cubase as a Automation.

Then after that, I did the same process again, and recorded the Automation Values in Pure Data. But these values arent as smoothe as I would like to have them, even I recorded them that slow, that I set a metro of 8 per second which is for the 14 Bit values something like half an hour. The faders are the most important feature of my Controller for me, so I take the right amount of time to get them very precisely.

Between: I also found out the SysEx values to display what I want on my two rows houston display with Pure Data which was fun.

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.