fixed a tk regression/bug with patch window sizes on osx. updated on release page

@seb-harmonik.ar would it be possible to update your mod to pd source 0.51.4 ?
The next ceammc lib will need last pd to have all of the features

@60hz I'm not aware of any new features since 0.51.3 (which ones would ceammc need?), but I went ahead and updated anyways (w/ an improved "font" dialog & fix to "stretch")
https://github.com/sebshader/pdnext/releases/tag/0.51-4

@seb-harmonik.ar
That's great!
All is working nicely with the next ceammc pre-release, the only drawback I see is that all tick boxes doesn't work in ceammc properties:
https://github.com/uliss/pure-data/issues/118#issue-830759712

I think it might be related to tcl/tk 8.6.11...

@60hz do you get that with vanilla too or just w/ next? vanilla distribution is still using 8.6.10 afaik
edit: I downloaded the library, which properties do you mean?

yes, it works well with vanilla in OSX 10.15.4 for me.

I talked about the Right clic -> property on any ceammc ui objects

@60hz I figured it out, seems like you're right. Might be pertinent to mention in the bug report that it only doesn't work with tcl/tk > 8.6.10

@seb-harmonik-ar
I have many little ui bug with the last version of next compiled with tcl/tk 8.6.11
https://github.com/sebshader/pdnext/issues/2

Is there any needs for this pecific tcl version?

@60hz I replied in the bug report, but basically the event loop handling is supposed to be much more stable and improved on modern macos with 8.6.11 from my understanding. For instance, 8.6.10 required patching to get the scrollbars to show up on newer osx (also this is why there are 2 different releases for osx on miller's site I think). The patch was kind of hacked out of 8.6.11 which changed the architecture of its event handling since 8.6.10.

I noticed the bug you mentioned in an earlier release with tk 8.6.10, and the fix was actually merged into main pd vanilla. I cannot reproduce on osx 10.14.6 so unfortunately I'm not sure how to go about fixing it..

as for the ceammc bug, it is an issue with tk 8.6.11 with the ttk "alt" theme and has to be fixed in either ceammc or tk.
However you can still package w/8.6.10, I suppose I can upload a version using it instead if it makes that big of a difference..

@60hz ok I just uploaded a version w/ tk 8.6.10 anyways

thanks @seb-harmonik.ar, I will try the tcl 8.6.10 version with ceammc.

And your are right about the patch bug, it was my mistake, I just messed with some tcl files and forgot about it, so sorry for the noise!

I'd love me some bezier patch chords Is it possible with vanilla (0.51.4)? If not, what's the steps I need to take to try it out? I'm on linux if that matters...

@a773 they look kinda ugly tbh. For linux you need to compile yourself, because of the variety of distros. (clone the pdnext repo, then follow the normal steps to make & install pd, hopefully just with "./configure" and then "make install" in the directory on the command line.)

After all of that, you can either use the menu item in the preferences submenu to turn the bezier curves on, or put the line set ::curve_cords 1 in some .tcl file in the pd path before starting pd if you want it saved.

to make the cords change when the menu item is selected (rather than when the window is opened) put the code with the "redraw_cords" proc above in some .tcl file in the pd path.

Thanks, that worked great!

Could you explain what pdnext is? I'm not sure if this is your fork with unofficial mods or the official repo or something completely different....

@a773 the first, basically it's my fork with features that haven't been accepted into vanilla yet.
The main one being the ability to set colors for everything. (but the bezier cables are there too)
It's fully compatible with pd-vanilla. (all patches for vanilla will work, and visa-versa. Nothing is changed except aesthetics)

@seb-harmonik.ar

Was actually thinking about this yesterday, why it is not enrolled into the Vanilla release.

It has been talked about many times in the Facebook group and also here, I guess

After running the mod a few days here are a few observations

1. selecting a chord seems to be a bit off, almost like you need to click where the “old” straight chord would have been.
2. setting curved lines in menu and save all prefs should save curves as well (shouldn’t be defined in tcl).
3. it doesn’t scale with ctrl+, I expected the curves to be twice as big, but they are the same, except obviously connecting to points further apart.

I have no idea how hard it would be to change any of the above, or if that’s the reason it’s not accepted in vanilla (or even if it’s been discussed/proposed).

@a773

1. Yes I know selecting the cord is off. The reason is that pd handles all mouse/geometry logic in c, in the main "pd" thread, rather than the tcl/tk process. This is not ideal at all, ideally all audio processes would happen in one thread and gui logic would be on another thread entirely (which is what Purr-Data and now Pd-l2ork have done. It should be done for vanilla as well, that's a big project that has been on the horizon for a while).
   Anyways, the result of that is that the "selection" logic is still using straight line geometry, and it would take further substantial modifications for pd to know if bezier curves are being drawn, and for it to know if they're being clicked on. (in terms of geometry math/logic). And, even if it were done doing so would further slow down the same thread that the audio is running on since bezier curve equations are more complex than linear ones.

2. I declined to add the cables to the preferences because I want full compatibility with vanilla and would have to change the preference file. (Like if you save preferences in vanilla and then open Next up the preference would be unset again. Having it set in a .tcl file avoids that). If it were accepted into vanilla perhaps the preference could be added.

3. I'll look into this and see if something can be done.. I hardly ever use zoom myself.

@a773 what system are you on? on osx the line width change from zooming is the same as with straight cables

I totally understand your approach, and agree that as a mod it's implemented quite elegantly. Sounds like esp 1) is what's keeping it out of mainstream vanilla.

I'm on linux...

Here are screenshots of "small" zoom, "big" zoom and then the "small" zoom manually made 2x as big in gimp. Except for the blur (obviously), I'd expect the path of the curves in the "big" zoom to look like the manually enlarged one. For instance notice how the curve goes into the metro on the small one, but doesn't on the zoomed in one.