Re: [PD-dev] Whoops, pushed to master
I did try a force push *immediately* but since the branch was locked it was rejected. I took that as a sign to revert. I generally avoid force pushing unless the repo is used by me or only a very small number of people. > On Jun 3, 2024, at 9:14 AM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Sun, 2 Jun 2024 23:40:21 +0200 > From: IOhannes m zm?lnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Whoops, pushed to master > Message-ID: <35c749e7-60b5-4228-8492-67c0358ac...@iem.at > <mailto:35c749e7-60b5-4228-8492-67c0358ac...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/2/24 21:37, Christof Ressi wrote: >> Hi Dan, >> >> On 02.06.2024 14:40, Dan Wilcox wrote: >>> Howdy all, >>> >>> sorry, I accidentally pushed a couple of commits to the master branch. >>> I reverted them after I realized. I suppose there is no clean way to >>> handle this otherwise. >> >> No worries, this has happened to me as well :) In the future, this is >> what you can do: >> >> 1. GitHub: in the repo settings (temporarily) enable force pushing to >> master >> >> 2. git reset >> >> 3. git push -f >> >> 4. GitHub: disable force pushing to master again > > > this is what i would do (and have done!) in the same situation as well. > > i was going to suggest that i could do that for dan, but miller has > already pushed on top your reverting commits, so I guess somebody will > have to live with eternal shame (or just keep contributing) :-) Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] d_osc.c needs to define M_PI for Windows
Howdy Miller, sorry, I can't make a PR for this right now but just a note: it looks like the CI Windows build fails because Windows does not define M_PI by default, although this might be for an *older* version of Windows/VS. I think it would be safe to check if M_PI exists in d_osc.c then define a reasonable default if not. Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] Whoops, pushed to master
Howdy all, sorry, I accidentally pushed a couple of commits to the master branch. I reverted them after I realized. I suppose there is no clean way to handle this otherwise. In any case, they are small updates to the dialog/preference section headers regarding case usage (for consistency). In this branch now I "un-revert" the now reverted commits on the master branch. Ugg, apologies -> https://github.com/pure-data/pure-data/pull/2332 ---- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] portmidi update
Thanks for the reply, don't worry about testing then. I re-read the discussion and checked the newer Portmidi code to confirm the changes we requested are in place, except that LIMIT_RATE is still hard-defined in the sources. I updated the patch to add #ifndef blocks around it so we can still override. It seems as though they did update the logic to detect if the port is an IAC virtual device or not but I think we should continue to disable the rate limit for now. Also, nice to see a number of warnings disappear when building the newer Portmidi on macOS. > On May 15, 2024, at 9:06 AM, cyrille henry wrote: > > Hello Dan, > > I guess you are talking about this : > https://github.com/pure-data/pure-data/issues/581 > > unfortunately, I found the problem on someone else computer. I don't have any > mac. So I can't test. > (I can test on my linux laptop if needed) > > cheers > c > > > > Le 15/05/2024 à 00:40, Dan Wilcox a écrit : >> Howdy all, >> I noticed Miller needed to make a change to the portmidi sources and that >> the update script is out of date as it still uses the old Portmidi >> Sourceforge SVN link. I have updated the script to now use the active >> Portmidi Github repo and made a PR: >> https://github.com/pure-data/pure-data/pull/2305 >> <https://github.com/pure-data/pure-data/pull/2305> >> As it's late in the release process, I haven't updated the sources >> themselves yet as I first wanted to check that the macOS midi rate limiting >> patch is still being applied successfully. This is the only major patch we >> need to apply for now. >> @Cyrille: Can you check that this macOS arm64 build sends & receives MIDI >> ok? I believe you first noticed the issue back around 2018. >> http://docs.danomatika.com/pdbuilds/0.55/Pd-0.55.0-pm-no-ratelimit.zip >> <http://docs.danomatika.com/pdbuilds/0.55/Pd-0.55.0-pm-no-ratelimit.zip> >> >> Dan Wilcox >> danomatika.com <http://danomatika.com> >> robotcowboy.com <http://robotcowboy.com> Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] portmidi update
Howdy all, I noticed Miller needed to make a change to the portmidi sources and that the update script is out of date as it still uses the old Portmidi Sourceforge SVN link. I have updated the script to now use the active Portmidi Github repo and made a PR: https://github.com/pure-data/pure-data/pull/2305 As it's late in the release process, I haven't updated the sources themselves yet as I first wanted to check that the macOS midi rate limiting patch is still being applied successfully. This is the only major patch we need to apply for now. @Cyrille: Can you check that this macOS arm64 build sends & receives MIDI ok? I believe you first noticed the issue back around 2018. http://docs.danomatika.com/pdbuilds/0.55/Pd-0.55.0-pm-no-ratelimit.zip ---- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] libpd Makefile still doesn't clear extras (aded note now)
Howdy all, I *thought* I fixed this, but libpd/Makefile in the pure-data repo (not the separate libpd repo), still does not correctly clear the object files out of the extra subdirectories, ie. extra/bob~/bob~.o, etc. In any case, I pushed a small commit to the develop branch adding a note about this to readme. I don't feel like figuring out the VPATH trickery to properly fix this. In the separate libpd repo Makefile, we use full paths. ;) Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] trouble with Pd version strings
PD_VERSION_CODE was added and shows up in the grep output as a second line. The fix is to simply filter it out when grabbing the values. A fix is here: https://github.com/pure-data/pure-data/pull/2298 > On May 8, 2024, at 9:27 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 4 > Date: Wed, 8 May 2024 21:29:43 +0200 > From: Miller Puckette <mailto:mpucke...@cloud.ucsd.edu>> > To: Alexandre Torres Porres mailto:por...@gmail.com>> > Cc: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] trouble with Pd version strings > Message-ID: <58043f32-0a8d-4aa9-9a03-a070d6c45...@cloud.ucsd.edu > <mailto:58043f32-0a8d-4aa9-9a03-a070d6c45...@cloud.ucsd.edu>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > No, it's a conflict between doc/Makefile.am and recent changes in > m_pd.h.? doc/Makefile.am is quite fragile and a seemingly > reasonablechange to m_pd.h broke it.? I have to get to a couple of other > things now but will try to figure out what to do tomorrow... possibly > just take the version-number-setting hack out of the doc :) > > cheers > > M Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Multiple audio devices?
I think the preference on macOS is to let the system do it via Aggregate Device. I'm not sure if PortAudio handles this as well on the platform. It might work but I'm sure using Audio MIDI Setup to do it is better. > On Apr 13, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Fri, 12 Apr 2024 23:11:41 +0200 > From: Max mailto:abonneme...@revolwear.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Multiple audio devices? > Message-ID: <4d9ef88a-002e-46cc-9bea-d7a4a5cc2...@revolwear.com > <mailto:4d9ef88a-002e-46cc-9bea-d7a4a5cc2...@revolwear.com>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 12.04.24 21:59, Alexandre Torres Porres wrote: >> And I wonder why we can't do this on mac. It would be cool and would >> help me a lot > > I think the OS can do it on Mac (over a decade ago that I've used Macs, > but back then it was called "aggregate device" and you set up such meta > device which is composed of multiple soundcards. It exposes then the sum > of the inputs/outputs to the system). > > I have no idea about the rationale not to include that function in Pd on > Mac, but I assume it's better if the OS is doing it. From what I > understood Apple is doing resampling anyway to compensate for clock > drifts, just like pipewire does on Linux. > > https://support.apple.com/en-us/102171 Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] threads
> I work with PD when I want to make music more than I want to do advanced CS. > And then there's the question of the marginal utility of PD having its own > implementation of a ringbuffer, but I will leave that for all of you who have > dedicated far more time than I to the maintenance of this project. ...please don't let that stop you. I want to dedicate more time to making music myself! > To be more specific: the libpd ringbuffer uses atomic read-modify-write > operations (with dummy arguments) instead of atomic loads and stores. > Again, these are hacks from pre-C11 times. Unfortunately, the C11 > version follows this pattern instead of using the more appropriate > atomic_load[_explicit] and atomic_store_[explicit] functions. Also, it > implicitly uses the default memory ordering (memory_order_seq_cst) for > all atomic operations, which is much stronger than what we actually need. That's my fault. I did not have much time when I did that update, so I just found the equivalent functions without changing anything to be conservative. If you have suggestions for improvement, I am open to it. We can also ping Peter. Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] threads
It's the implementation used by libpd for passing messages between the audio
thread to the various hooks. It is also used in the libpd Obj-C PdAudioUnit for
buffering samples sample rate conversion is happening and the buffer size is
inconsistent. If it was broken in some way, we would have heard about it over
the last 10+ years or so. I trust the guy who wrote it (Peter Brinkmann) but it
is admittedly older code now and I only updated to C atomics in a cursory
manner via the macros. If y'all have thoughts/suggestions on improvement,
please open an issue (or better a PR) on the libpd Github repo.
> On Apr 11, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:
>
> As an aside: is the code in z_ringbuffer.{c,h} considered trustworthy? I
> note that the other code in PD appears to use the sys_ringbuffer* API,
> which seems to be built on the PA ringbuffer. I ask because I had some
> problems with z_ringbuffer.c and after a code read, there are some bits
> which look sketchy enough to me that I decided to stop using it.
Dan Wilcox
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Seeking co-maintainers for Scheme for Pd
+1 If people use it, it will be maintained. It's best if someone can act as a general maintainer to help coordinate submissions from the general community. The pd-externals group makes it relatively easy for this unless you want to keep the project within your user space specifically. If transferred, you can still be the owner of the repository with full access to it. > On Mar 20, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Tue, 19 Mar 2024 13:09:27 +0100 > From: IOhannes m zm?lnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Seeking co-maintainers for Scheme for Pd > Message-ID: <29d3083f-0419-4c7a-a1b6-fbdb29169...@iem.at > <mailto:29d3083f-0419-4c7a-a1b6-fbdb29169...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 3/17/24 06:14, Iain Duncan wrote: >> It occurred to me thinking further that really one doesn't need to know >> much about Scheme or Lisp, provided one is interested, as I didn't when I >> started! The work is mostly in C. FWIW. :-) > > how about moving the repository to <https://github.com/pd-externals/> ? > there are always? some volunteers who can help with bugfixing and the > like, and if someone is willing to dig deeper into scheme4pd, they can > always join (and leave, if need be). > > in general i think the pd-externals group is a good place for small > team-maintained externals. > > > personally, i am interested in that external (and have plenty of C > skills) - but honestly I have other things on my plate as well, so > couldn't do a full time maintenance o fthe project. > > gfmards > IOhannes Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] release April?
My 2 cents: baby, bathwater. The IME GUIs may not be *perfect* but they, so far, have been *good enough*. I am always fearful of trying to design & implement the "one *whatever* to rule them all" as making something too generic ends up being more complicated then the simplest approach, with some amount of code sharing to avoid redundancy. (That being said, I am only reacting and maybe you have something in mind which deals with this.) I think we can consider ways to overhaul the existing ones for sure. For instance, I have a balanced approach to implementing the GUIs in Pdparty using Apple frameworks using single-inheritance OO: https://github.com/danomatika/PdParty/tree/master/src/gui There is a Widget class which everything else inherits from. Then shared code within IEMWidget class which Bang, Slider, etc use. I don't think this is far off from the recent refactors in the IEM widget code base over the last years. > On Mar 15, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Date: Thu, 14 Mar 2024 14:36:50 +0100 > From: Christof Ressi mailto:i...@christofressi.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] release April? > Message-ID: <24adbd83-47b5-4fbd-bbc9-2fb56d69f...@christofressi.com > <mailto:24adbd83-47b5-4fbd-bbc9-2fb56d69f...@christofressi.com>> > Content-Type: text/plain; charset=UTF-8; format=flowed > >> Anyway, I've been holding off on introducing yet one more ad-hoc GUI >> device until I (or someone :) can make a properly unified GUI for >> numerical controls. > Is this realistic? And does it really warrant withholding a proper knob > UI for another couple of years (or even forever)? > > A knob would not prevent a "unified numerical control" in the future. > Yes, it would be one more legacy object to deal with, but does it really > matter at this point? It's not like we're constantly adding new UI > elements. The last time was probably 20 years ago :) I guess if Thomas > Musil made one back in the day, we would have it anyway. > > A more general question: what would the advantage of such a "unified" > GUI object, in particular for the user? I guess the idea is that you can > easily turn any numeric GUI element into another? > > Cheers, > > Christof Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] release April?
Even better. Then it has been in testing for a *long* time now. ;) > On Mar 14, 2024, at 1:44 PM, Christof Ressi wrote: > > I think Antoine's knob implementation is actually based on mknob, but with > lots of refinements. > > On 14.03.2024 13:39, Dan Wilcox wrote: >> I agree. >> >> There is also the mknob from moonlib which I have actually replicated for >> PdParty. I think both of these knob implementations fit nicely with the >> other IEM guis. >> >>> On Mar 14, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at >>> <mailto:pd-dev-requ...@lists.iem.at> wrote: >>> >>> Date: Wed, 13 Mar 2024 13:10:19 +0100 >>> From: Christof Ressi >> <mailto:i...@christofressi.com>> >>> To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> >>> Subject: Re: [PD-dev] release April? >>> Message-ID: >> <mailto:f8bc28fd-f54c-4814-828b-686aa2fbf...@christofressi.com>> >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>> >>> I strongly endorse both PRs :) >>> >>> Fractional zoom levels would be a game changer! The current integer zoom >>> levels are pretty much useless in practice because typical scaling >>> factors are more like 125% or 150%. >>> >>> A knob is such a basic UI element for audio applications. I really think >>> this should be part of Pd vanilla and not require some external. It >>> isn't (only) about aesthetics; knobs have clear advantages over sliders >>> in many situations as they allow to map the same range into a much >>> smaller space. Just think about a simple mixer strip! >>> >>> Christof >> >> >> Dan Wilcox >> danomatika.com <http://danomatika.com/> >> robotcowboy.com <http://robotcowboy.com/> Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] release April?
I agree. There is also the mknob from moonlib which I have actually replicated for PdParty. I think both of these knob implementations fit nicely with the other IEM guis. > On Mar 14, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Date: Wed, 13 Mar 2024 13:10:19 +0100 > From: Christof Ressi mailto:i...@christofressi.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] release April? > Message-ID: <mailto:f8bc28fd-f54c-4814-828b-686aa2fbf...@christofressi.com>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > I strongly endorse both PRs :) > > Fractional zoom levels would be a game changer! The current integer zoom > levels are pretty much useless in practice because typical scaling > factors are more like 125% or 150%. > > A knob is such a basic UI element for audio applications. I really think > this should be part of Pd vanilla and not require some external. It > isn't (only) about aesthetics; knobs have clear advantages over sliders > in many situations as they allow to map the same range into a much > smaller space. Just think about a simple mixer strip! > > Christof Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] release April?
Howdy Miller,, sounds good. I agree with Christof that many of us have Easter vacation coming, so activity may go down. I can highlight some current PRs. A fix needed for libpd: fix pd_this on Windows https://github.com/pure-data/pure-data/pull/2165 A couple of things I would really highlight as they are user experience paper cuts for many people. Plus, both PRs have been in development and use for some time by people doing self-builds and or through pd-next: add tcl color variables to pd https://github.com/pure-data/pure-data/pull/196 snap to grid https://github.com/pure-data/pure-data/pull/739 There are also a number of gop fixes & updates in Christofs PRs which I think are important as they solve some common issues for people making custom GUIs. > On Mar 12, 2024, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Date: Tue, 12 Mar 2024 08:47:51 +0100 > From: Miller Puckette <mailto:mpucke...@cloud.ucsd.edu>> > To: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] release April? > Message-ID: <mailto:d4021fe8-9dfc-4f91-b2a3-d7d1da43f...@cloud.ucsd.edu>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > To Pd dev - > > I'm thinking of making a release mid April (assuming things go well) and > so I should probably call for a freeze late March.? As usual I plan to > merge in "devel" and "Documentation" - in fact I should do a first merge > rather soon, assuming things are in a good state for merging. > > I'm planning to add a couple of features: 1. message to Pd to toggle > between GUI and no-GUI -- perhaps with a way to reset the GUI startup > command -- so that if you have a headless installation that's doing > something funny you can pop it open and look; and 2. improvements to the > "pointer" object to make it easier to get around data structures, and > possibly a menu extension for dragging new "data" onto the screen; 3. an > optional pop-up display showing (x,y) coordinates of object or data knob > being dragged. > > Incidentally: I just noticed that the IEM slider object (and proabbly > other EM GUIs) spits out a number when clicked upon, even if not > dragged.? Is this desirable behavior?? It caught me out buit perhaps > other users are actually wanting to be able to click on a control to > repeat its value.? Hmm.. > > cheers > > Miller Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] https, msp.ucsd.edu and file downloads.
I agree. Both http and https downloads could be supported by using relative paths in the html a tags: This should work as the site host is msp.ucsd.edu <http://msp.ucsd.edu/> and the relative path would be append: http or https + :// + msp.ucsd.edu <http://msp.ucsd.edu/> + /Software/$$$ > On Oct 25, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Tue, 24 Oct 2023 23:42:54 -0300 > From: Lucas Cordiviola mailto:lucard...@hotmail.com>> > To: mpucke...@cloud.ucsd.edu <mailto:mpucke...@cloud.ucsd.edu> > Cc: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] https, msp.ucsd.edu <http://msp.ucsd.edu/> and file > downloads. > Message-ID: > > > <mailto:ia1pr19mb7663c08254a20320483350bea6...@ia1pr19mb7663.namprd19.prod.outlook.com>> > > may be the safer way to allow links to work on both types of connections > (http and https) is to give relative URLs (stripping 'http://msp.ucsd.edu > <http://msp.ucsd.edu/>') > > ??? > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] time for a quick bugfix update?
Ok, this back ported patch is in the latest develop branch commit. I have made new test builds with Tk 8.6.13 + the patch applied so the framework is now weakly linked and these should work on older macOS versions, as before. New builds are marked "-fixed" and found at: http://docs.danomatika.com/pdbuilds/0.54/ To confirm: % otool -L Pd-0.54-0-arm64-tk8613.app/Contents/MacOS/Pd | grep Uniform /System/Library/Frameworks/UniformTypeIdentifiers.framework/Versions/A/UniformTypeIdentifiers (compatibility version 1.0.0, current version 709.0.0, weak) The "weak" is the important part. :) > On Oct 23, 2023, at 11:33 PM, Dan Wilcox wrote: > > Ok, I have a fix for the library issue on older macOS versions... actually > back ported from TK itself: > > https://github.com/tcltk/tk/commit/a3eb1edc6e9c2eb227b40c7d46f42e6162be78d6 > > I will fold this in as a custom patch we apply when building the downloaded > tarball, as before. > > 8.6.13 was released last November. Judging from the current development > activity, there should be an 8.6.14 release fixing quite a number of macOS > 14-related stuff. > > It might make sense to put out a 0.54-1 bugfix release with 8.6.13 then > follow up again with 8.6.14 when it comes out, either via 0.54-2 or 0.55-0. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] time for a quick bugfix update?
Ok, I have a fix for the library issue on older macOS versions... actually back ported from TK itself: https://github.com/tcltk/tk/commit/a3eb1edc6e9c2eb227b40c7d46f42e6162be78d6 I will fold this in as a custom patch we apply when building the downloaded tarball, as before. 8.6.13 was released last November. Judging from the current development activity, there should be an 8.6.14 release fixing quite a number of macOS 14-related stuff. It might make sense to put out a 0.54-1 bugfix release with 8.6.13 then follow up again with 8.6.14 when it comes out, either via 0.54-2 or 0.55-0. > On Oct 23, 2023, at 9:37 PM, Dan Wilcox wrote: > > There shouldn't need to be any patches applied. I double-checked and the last > patch for 8.6.12 is integrated into 8.6.13 itself. > > As for running an 8.6.13 Wish on earlier macOS versions... well that is an > issue. The builds I had made all link to the UniformTypeIdentifiers framework > which apparently was added to macOS 11 and later. Running this Wish on > earlier versions seems to crash due to the load not finding the framework. > What's interesting is that the Tk build system is supposed to weak link to it > yet the loader still exits the app on start. > > See the thread starting here: > https://github.com/pure-data/pure-data/issues/2105#issuecomment-1774233455 > >> On Oct 23, 2023, at 5:16 PM, pd-dev-requ...@lists.iem.at wrote: >> >> Message: 3 >> Date: Mon, 23 Oct 2023 17:16:42 +0200 >> From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> >> To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> >> Subject: Re: [PD-dev] time for a quick bugfix update? >> Message-ID: > <mailto:d3f803ab-9216-4e5b-8e15-ad619f1ba...@iem.at>> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> On 10/23/23 13:21, IOhannes m zmoelnig wrote: >>> On 10/23/23 11:56, Miller Puckette wrote: >>>> Hi list - >>>> >>>> I've merged the update and documentation branches, and will merge the >>>> translation support pretty soon. >>>> >>>> I don't know where in Iohannes's CI scripts the TCL/TK version gets >>>> specified for MacOS (and I can't get to a Macintosh until next week >>>> maybe to check this)... so will have to wait for word from Iohannes as >>>> to when I can grab a TCL-TK-correct version from CI.? Once I believe >>>> that's in place I'll imeddiately put out a 'test' version of 0.54-1... >>>> >>> >>> thanks for checking back. >>> >>> indeed the Tcl/Tk version that is used for the CI builds is currently >>> 8.6.12, i will try to update them asap. >>> >>> @dan before i do so, i would like to make sure that the Tcl/Tk binaries >>> are backwards compatible: >>> - arm64 should run on BigSur (and later) >>> - x86_64 should run on Yosemite (and later) >> >> >> ah well. >> i've created universal builds of Tcl/Tk-8.6.13 myself (on BigSur), but >> ran into the same problems as alexandre [1], with the binaries not being >> compatible with older versions of macOS (i tested on Sierra). >> i'll try to build the x86_64 portion on some older mac (there's a >> mavericks machine somewhere...) and see how this turns out. >> >> sorry for the delay. >> >> gfmasdr >> IOhannes >> > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] time for a quick bugfix update?
There shouldn't need to be any patches applied. I double-checked and the last patch for 8.6.12 is integrated into 8.6.13 itself. As for running an 8.6.13 Wish on earlier macOS versions... well that is an issue. The builds I had made all link to the UniformTypeIdentifiers framework which apparently was added to macOS 11 and later. Running this Wish on earlier versions seems to crash due to the load not finding the framework. What's interesting is that the Tk build system is supposed to weak link to it yet the loader still exits the app on start. See the thread starting here: https://github.com/pure-data/pure-data/issues/2105#issuecomment-1774233455 > On Oct 23, 2023, at 5:16 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 3 > Date: Mon, 23 Oct 2023 17:16:42 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] time for a quick bugfix update? > Message-ID: <mailto:d3f803ab-9216-4e5b-8e15-ad619f1ba...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 10/23/23 13:21, IOhannes m zmoelnig wrote: >> On 10/23/23 11:56, Miller Puckette wrote: >>> Hi list - >>> >>> I've merged the update and documentation branches, and will merge the >>> translation support pretty soon. >>> >>> I don't know where in Iohannes's CI scripts the TCL/TK version gets >>> specified for MacOS (and I can't get to a Macintosh until next week >>> maybe to check this)... so will have to wait for word from Iohannes as >>> to when I can grab a TCL-TK-correct version from CI.? Once I believe >>> that's in place I'll imeddiately put out a 'test' version of 0.54-1... >>> >> >> thanks for checking back. >> >> indeed the Tcl/Tk version that is used for the CI builds is currently >> 8.6.12, i will try to update them asap. >> >> @dan before i do so, i would like to make sure that the Tcl/Tk binaries >> are backwards compatible: >> - arm64 should run on BigSur (and later) >> - x86_64 should run on Yosemite (and later) > > > ah well. > i've created universal builds of Tcl/Tk-8.6.13 myself (on BigSur), but > ran into the same problems as alexandre [1], with the binaries not being > compatible with older versions of macOS (i tested on Sierra). > i'll try to build the x86_64 portion on some older mac (there's a > mavericks machine somewhere...) and see how this turns out. > > sorry for the delay. > > gfmasdr > IOhannes > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] time for a quick bugfix update?
There is also now a universal build with Tcl/Tk 8.6.13, same place: http://docs.danomatika.com/pdbuilds/0.54/ > On Oct 23, 2023, at 1:23 AM, Dan Wilcox wrote: > > Ok, added an x86_64 build as well. Both are in: > > http://docs.danomatika.com/pdbuilds/0.54/ > > I have to do separate builds as building a universal Wish.app still fails for > some reason. I was hoping it would be fixed in a new version of Tk but maybe > the fault lies in the mac/tcltk-wish.sh script? > >> On Oct 23, 2023, at 12:59 AM, Dan Wilcox wrote: >> >> Here is an arm64 build using Tk 8.6.13: >> >> http://docs.danomatika.com/pdbuilds/0.54/Pd-0.54-0-arm64-tk8613.zip >> >>> On Oct 22, 2023, at 4:32 PM, Dan Wilcox wrote: >>> >>> I will try to check this tonight as we may/may not need to update the >>> custom patches which are applied when building Tk for Pd. >>> >>> IN general, I think it's a good idea to make a 0.54-1 bugfix release for >>> this as well as include the small changes in the develop branch which >>> include a fix required for libpd... then I can make a libpd release too. >>> >>>> On Oct 22, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: >>>> >>>> Message: 1 >>>> Date: Sat, 21 Oct 2023 13:57:07 -0300 >>>> From: Alexandre Torres Porres mailto:por...@gmail.com>> >>>> To: pd-dev mailto:pd-dev@lists.iem.at>> >>>> Subject: [PD-dev] time for a quick bugfix update? >>>> Message-ID: >>>>>>> <mailto:CAEAsFmjyVNDQXX7oHGNWw=43LS_aTcAhr1Z-8C=btnlb7jh...@mail.gmail.com>> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Hi, we have an issue with the latest macOS, see >>>> https://github.com/pure-data/pure-data/issues/2105 >>>> >>>> It seems an upgrade of tcl/tk is required and it would be worth a bugfix >>>> release as I see it. What do people say? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] time for a quick bugfix update?
Ok, added an x86_64 build as well. Both are in: http://docs.danomatika.com/pdbuilds/0.54/ I have to do separate builds as building a universal Wish.app still fails for some reason. I was hoping it would be fixed in a new version of Tk but maybe the fault lies in the mac/tcltk-wish.sh script? > On Oct 23, 2023, at 12:59 AM, Dan Wilcox wrote: > > Here is an arm64 build using Tk 8.6.13: > > http://docs.danomatika.com/pdbuilds/0.54/Pd-0.54-0-arm64-tk8613.zip > >> On Oct 22, 2023, at 4:32 PM, Dan Wilcox wrote: >> >> I will try to check this tonight as we may/may not need to update the custom >> patches which are applied when building Tk for Pd. >> >> IN general, I think it's a good idea to make a 0.54-1 bugfix release for >> this as well as include the small changes in the develop branch which >> include a fix required for libpd... then I can make a libpd release too. >> >>> On Oct 22, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: >>> >>> Message: 1 >>> Date: Sat, 21 Oct 2023 13:57:07 -0300 >>> From: Alexandre Torres Porres mailto:por...@gmail.com>> >>> To: pd-dev mailto:pd-dev@lists.iem.at>> >>> Subject: [PD-dev] time for a quick bugfix update? >>> Message-ID: >>> >> <mailto:CAEAsFmjyVNDQXX7oHGNWw=43LS_aTcAhr1Z-8C=btnlb7jh...@mail.gmail.com>> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi, we have an issue with the latest macOS, see >>> https://github.com/pure-data/pure-data/issues/2105 >>> >>> It seems an upgrade of tcl/tk is required and it would be worth a bugfix >>> release as I see it. What do people say? >> >> >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika> >> danomatika.com <http://danomatika.com/> >> robotcowboy.com <http://robotcowboy.com/> >> >> >> > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] time for a quick bugfix update?
Here is an arm64 build using Tk 8.6.13: http://docs.danomatika.com/pdbuilds/0.54/Pd-0.54-0-arm64-tk8613.zip > On Oct 22, 2023, at 4:32 PM, Dan Wilcox wrote: > > I will try to check this tonight as we may/may not need to update the custom > patches which are applied when building Tk for Pd. > > IN general, I think it's a good idea to make a 0.54-1 bugfix release for this > as well as include the small changes in the develop branch which include a > fix required for libpd... then I can make a libpd release too. > >> On Oct 22, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: >> >> Message: 1 >> Date: Sat, 21 Oct 2023 13:57:07 -0300 >> From: Alexandre Torres Porres mailto:por...@gmail.com>> >> To: pd-dev mailto:pd-dev@lists.iem.at>> >> Subject: [PD-dev] time for a quick bugfix update? >> Message-ID: >> > <mailto:CAEAsFmjyVNDQXX7oHGNWw=43LS_aTcAhr1Z-8C=btnlb7jh...@mail.gmail.com>> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, we have an issue with the latest macOS, see >> https://github.com/pure-data/pure-data/issues/2105 >> >> It seems an upgrade of tcl/tk is required and it would be worth a bugfix >> release as I see it. What do people say? > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] time for a quick bugfix update?
I will try to check this tonight as we may/may not need to update the custom patches which are applied when building Tk for Pd. IN general, I think it's a good idea to make a 0.54-1 bugfix release for this as well as include the small changes in the develop branch which include a fix required for libpd... then I can make a libpd release too. > On Oct 22, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Sat, 21 Oct 2023 13:57:07 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] time for a quick bugfix update? > Message-ID: ><mailto:CAEAsFmjyVNDQXX7oHGNWw=43LS_aTcAhr1Z-8C=btnlb7jh...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hi, we have an issue with the latest macOS, see > https://github.com/pure-data/pure-data/issues/2105 > > It seems an upgrade of tcl/tk is required and it would be worth a bugfix > release as I see it. What do people say? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] comport "pollintervall" option
From the comport 1.2 help file:  > On Aug 29, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Mon, 28 Aug 2023 13:33:32 +0200 > From: Roman Haefeli mailto:reduz...@gmail.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] comport "pollintervall" option > Message-ID: <6a883c6ecb57904edc045fb363e15d27882c9da7.ca...@gmail.com > <mailto:6a883c6ecb57904edc045fb363e15d27882c9da7.ca...@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > On Mon, 2023-08-28 at 10:49 +0200, Dan Wilcox wrote: >> >> I am working on a project and am using the [comport] object. I >> noticed it has an option named "pollintervall" and my OCD on such >> things wonders if this can be "pollinterval" without the extra 'l' >> since the word is "interval". I wouldn't remove the original but add >> the second, possibly with a post to suggest the original is >> deprecated etc. > > ?? > > Roman Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] comport "pollintervall" option
Howdy all, I am working on a project and am using the [comport] object. I noticed it has an option named "pollintervall" and my OCD on such things wonders if this can be "pollinterval" without the extra 'l' since the word is "interval". I wouldn't remove the original but add the second, possibly with a post to suggest the original is deprecated etc. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] why must one never send a message from a perform routine ?
Well, I don't mean documentation all internal mechanisms but, in this case, it might have been helpful to at least note *which* functions should or shouldn't be called in which situations. For instance, I note which libpd functions *not* call when DSP is running. > On Aug 23, 2023, at 5:30 PM, Christof Ressi wrote: > >> so it would pay to fill out the header. > Yeah, all API functions in "m_pd.h" should really have minimal documentation > (preferrably doxygen). > > However, I'm not sure that "m_pd.h" is the place for documenting the inner > workings of Pd... I think the official manual would be a more natural place, > as it already serves this purpose. > > Anyway, once these things are written down somewhere, we can just post a link > whenever someone asks about them :) > > Christof > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] why must one never send a message from a perform routine ?
Joseph: Do not be embarrassed. Understanding the engine is relatively opaque IMO and info is scattered in different places. Christof: IMO these kinds of important details should really by in m_pd.h. The API is pretty stable at this point, so it would pay to fill out the header. This was my approach with libpd: https://github.com/pure-data/pure-data/blob/master/src/z_libpd.h We originally had docs for libpd on a wiki page but once things stabilized I did the painful, but IMO necessary, step to move it into minimal header documentation. This also made it trivial to include basic docs when libpd was integrated into the pure-data repo. > On Aug 23, 2023, at 5:05 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Wed, 23 Aug 2023 17:04:41 +0200 > From: Christof Ressi mailto:i...@christofressi.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] why must one never send a message from a perform > routine ? > Message-ID: <7a96c4d0-10ec-1d18-b016-df0304498...@christofressi.com > <mailto:7a96c4d0-10ec-1d18-b016-df0304498...@christofressi.com>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Glad that I could help! Very little of this is really documented > (accurately). Personally, I figured this out by reading the source code. > > Ideally, we should improve the official documentation in > http://msp.ucsd.edu/Pd_documentation/x3.htm#s1.0. Some things are > outdated, misleading or just plain wrong (in particular the section > "audio buffer size and block size"). I just put this on my > (ever-growing) TODO list. > > Christof Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] Closing old Github issues
Howdy all, I have Github notifications turned off on the main pure-data repo (otherwise I would go crazy), but I do check now and then. We have almost 400 open issues, many of which go back 5 years or so. Can we go through and close things which have been resolved or are simply inactive? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] switching app-id to info.puredata.pd?
I have thought about this before and yes I would do it, as long as the .info is and will be the main domain for the foreseeable future. We should consider adding a detection mechanism that checks if the new settings exist and, if not, imports the old settings. Perhaps this can be a dialog which pops up asking if the import is desired? In any case, a transition should be well-communicated so no one is surprised, ie. I have some scripts to swap out configurations which expect a certain path, etc. > On Aug 11, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > so my question is: could (and should) we switch the app-id from > "org.puredata..." to "info.puredata...", just in case we ever need to > *prove* that "we" actually own the domain. > > there are of course caveats: > Pd uses the "org.puredata" namespace for storing settings: > - the GUI settings (on all platforms) > - on macOS it is used for storing the "normal" Pd-settings as well > > so changing the namespace to "info.puredata" will discard all settings. > > > > what do you think? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] performance of different Wish versions
Maybe I do agree with you, actually. I just naturally try to push back on the "macOS is always changes and sucks" statements that come now and then from people who don't even use the platform. You original state was not one of these and I share the frustration (especially after the key handing patch pain). I think the point is more that, in our case, we are a bit unlucky in that this platform simply doesn't get the attention as much as other platforms for Tk. I certainly don't want to do Tk dev work unless I have to and, if it is as a point to where nobody is even trying to fix it any more, well, we should accelerate the generalized GUI comm interfaces in the core. ;) I just don't want to be quick to "jump ship" when 1. you, I, and IOhannes are likely the *only* ones to have any interest in doing the work for this while 2. there are *lots* of people using macOS and Pd. None of us need a large development responsibility when, I at least, am not paid to work on Pd in general. As someone who has developed native macOS and iOS apps, the APIs are pretty stable via Obj-C/ Swift and the version handling at runtime is relatively good. OTOH that's probably a different story with C though, considering it doesn't have the same kind of runtime flexibility. My point here is that it's not as bad as it is often portrayed *if* you do it the "Apple way" otherwise you are on your own. ;P One option would be to back port the important differences we need in Pd to 8.6.11 and release Pd with this Wish version for now, although that might be tricky as newer macOS versions come out. > On Jul 16, 2023, at 10:07 AM, Sebastian Shader wrote: > > yes, they've accepted our prs. But I'm not sure 'we' are up to keeping an > entire gui toolkit up-to-date with API changes, in addition to pd itself. > There's a reason that a gui toolkit is used, rather than building one from > scratch. Sure, I can open issues to fix alpha channels for checkbuttons or > help menu ordering issues (the latter of which I've helped fix on their end) > but when it comes to event handling that scope becomes quite a bit larger. > And if we are up to doing dev work on tcl/tk and accepting that > responsibility, then we should open some prs to make recent tcl/tk reasonably > performant on macos. But that hasn't happened. It's great if someone could > take on that job but as relatively small open source projects idk if anyone > will. > The fact is that seemingly, newer versions of tcl/tk have pretty bad > performance on macos. But the tcl/tk team doesn't even seem to be sure why > the performance is bad. > > Maybe we're calling 'update' inappropriately or something, but other than > that it is tk's responsibility and they haven't solved the issue. (and imo > the frequency of calling 'update' shouldn't be platform-dependent.. though > that might be unavoidable..). > In addition, tk's own devs seem to reference an 'api churn' by macos: Tk > Source Code: View Ticket (tcl-lang.org) > <https://core.tcl-lang.org/tk/tktview/f642d7c0f4> so at least THEY agree that > MacOS deprecates APIs more frequently than on the other main platforms. > > I don't even mind MacOS deprecating things frequently, I just think a gui > toolkit as old and small as tcl/tk is ill-equipped to adapt to it. Maybe > their architecture just can't deal with it well either, and/or there is some > kind of 'tech debt' in that regard? idk > Also personally I like tcl/tk, I just think MacOs isn't as well supported as > it could be, and the MacOs devs often seem eager to take an 'it's not an > issue' attitude even when whatever it is certainly is an issue. (but again, > it's an open source project that may be too small to get enough support for > these changes) > > -seb > > On Saturday, July 15, 2023 at 02:05:57 AM PDT, Dan Wilcox > wrote: > > > I disagree with this assessment. > > In recent years the macOS maintenance of Tk picked up quite a bit and it is > *much better* than before. It was always reacting as opposed to staying on > top of platform changes but they at least have integrated changes from our > end for sticky things like the key handling issues. > > I also disagree that macOS has “constantly changing” APIs and associated FUD. > Most changes are well documented in advanced and major changes often leave > deprecation mechanism in places for many years after (ie. Carbon). That these > updates come as a surprise to open source developers who don’t keep up with > all the minutia (myself much included) is not always Apples fault. > > Should we stick with Tk forever? Possibly not, but I don’t see issues like > this as always the next reason to drop it ASAP consider how difficult > cross-platform development is due to pl
Re: [PD-dev] performance of different Wish versions
I disagree with this assessment. In recent years the macOS maintenance of Tk picked up quite a bit and it is *much better* than before. It was always reacting as opposed to staying on top of platform changes but they at least have integrated changes from our end for sticky things like the key handling issues. I also disagree that macOS has “constantly changing” APIs and associated FUD. Most changes are well documented in advanced and major changes often leave deprecation mechanism in places for many years after (ie. Carbon). That these updates come as a surprise to open source developers who don’t keep up with all the minutia (myself much included) is not always Apples fault. Should we stick with Tk forever? Possibly not, but I don’t see issues like this as always the next reason to drop it ASAP consider how difficult cross-platform development is due to platform differences. It’s disappointing but kinda “par for the course.” enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com > On Jul 15, 2023, at 9:18 AM, pd-dev-requ...@lists.iem.at wrote: > > From: Sebastian Shader > To: "pd-dev@lists.iem.at" > Subject: [PD-dev] performance of different Wish versions > Message-ID: <22683916.267738.1689344746...@mail.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > From my brief interactions with making prs for tk, my impression was that > Wish development on macos isn't very healthy.Probably partly due to MacOS > changing APIs all the time and leaving developers to figure out how to > migrate in the best way. > There are a few different threads regarding performance issues with recent > wish and MacOS, but unless someone investigates it and opens up a ticket with > Tk to fix it it probably won't get fixed. > Tcl/tk that isn't recent has some little things that don't really work on > macos, so there's really nothing to be done on the pd side aside from > switching to another gui toolkit entirely. ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] performance of different Wish versions
I'd be curious to know if this is related to Pd itself *or* Tk? It appears to be the latter and the next test would be to write a minimal Tcl/Tk script which reproduces the behavior. It could be something like a single window with a Tk cnv and a rectangle which changes color in a loop. If the performance hit comes with just the Tcl script then we can open an issue with the Tk devs as there may be a regression. > On Jul 14, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 3 > Date: Thu, 13 Jul 2023 23:22:10 +0200 > From: Roman Haefeli mailto:reduz...@gmail.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] performance of different Wish versions > Message-ID: <1d9d56e5434211950cc1b1b363d84af42ff3b7f9.ca...@gmail.com > <mailto:1d9d56e5434211950cc1b1b363d84af42ff3b7f9.ca...@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hey all > > I was seeing a suspiciously high CPU usage (~52% in Acitivity Monitor) > on macOS with one of my patches basically idling. It turned out to be > the GUI process and not 'pd'. Then I figured out that it was related to > frequently changing the color of a [cnv] in a GOP. The same patch with > the same rate of color changes eats almost no CPU on Linux (4-5% in > htop). Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision pd?
My gut feeling is that this is best kept as two separate builds for the platform. IMO we don't want to have to resort to a lot of trickery fighting the system's preferred modus operandi as it will, as you write, likely blow up in our faces. > On Jun 12, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Mon, 12 Jun 2023 09:08:36 +0200 > From: IOhannes m zm?lnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] double precision pd? > Message-ID: <mailto:d02ebe17-dce6-98a3-b55c-0f923c5f7...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/8/23 15:23, IOhannes m zm?lnig wrote: >>> Oh no, compilation will be complex. >> >> Not really. >> You basically have to build twice... > > oh no, i forgot about the intricacies of the windows build. > > with macOS and Linux we have this nice single "pd" binary (or "pd64"). > but with Windows we need the supporting pd.dll library where all the > guts live (so externals have something to link against), and as of now, > double-precision externals on Windows will link against pd.dll as well > (but expect that to be contain the double-variant). Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision pd?
It will work and I don't think separate apps would be needed. The executable within the .app bundle (Contents/MacOS/Pd) is just the renamed Wish executable which calls the Tk GUI which, in turn, starts the pd core which could be either 32 or 64 bit float precision. This could be selectable via a GUI preference which would take effect on app restart. A bigger issue might be if the core is also sending 64 bit doubles to the GUI but the GUI is not set up for that, although I don't believe that is the case as, at that point, things are sent as stings, ie. the contents of a wide float atom. > On Jun 9, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > For the macOS app, I don't know whether it will work (but of course the > downloadable dmg could provide both apps, and it might compress well enough > that the additional content won't be a problem) Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision pd?
Yeah, after batting names around, I think "pd64" is the simplest even if it potentially runs into architecture naming. It's definitely true we are well past the 32 - 64 bit transition at this point anyway. If it worked for CSound it can work for us and, really, most other naming is clunky IMO. This just needs a good explanation so the usage of 64 is clear: 64-bit double precision floats and support for very long sound files (via CAF). > On Jun 8, 2023, at 11:15 AM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Wed, 7 Jun 2023 16:42:53 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] double precision pd? > Message-ID: <5cf4aa6d-c70e-8fd3-993a-e4d1b49d1...@iem.at > <mailto:5cf4aa6d-c70e-8fd3-993a-e4d1b49d1...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/7/23 12:55, Antoine Rousseau wrote: >> Le mer. 7 juin 2023 ? 10:47, Lucas Cordiviola > <mailto:lucard...@hotmail.com>> a >> ?crit : >> >>> For me pd64 gives more chances of confusion than pdd or pdpd. >>> >> (...) >> >>> Starting with a new name of the app seems the most sane. >>> >> >> Funnily, my personal feeling is the opposite :-) >> I feel that Pd64 clearly describes Pd working with 64 bit data. > [...] >> >> To me, "pdd" or "pdpd" really sound like different apps, which I find a bit >> strange (it's actually the same app, only different options). > > that's also my personal feeling. > > double-precision Pd ist just a variant, and pdpd is hard to read (once > you leave the Pd universe). > > on my system i can install "libpdl, libpdb-redo, libpda-* packages, and > I'm not overly enthusiastic about finding a "libpdpd" in this list. > probably the library version is not so important, so with applications > it is: "pdal, pdd, pdf, pdl, pdb", and having a "pdpd" in there seems > also hard to sport. > > my brain is just faster with keeping number (like "64" or "2") apart > from alpha-chars... > > >> I quite like Pd? or even Pd2, though. > > i like them too, esp the "Pd?" looks good and has a nice ring, but of > course this is not an ASCII-compatible name and thus a no go. > > with Pd2, i guess people will wonder when they missed the v1.0 release > of Pd though (something I don't see happening with Pd64). > > > as a reference, the venerable Csound (which i think has been using > double precision as the internal data representation for >10 years no), > is (still) using csound64 (as in "csound64.dll") for the > double-precision (even though it no longer offers any single-precision > variant). > afaict this is independent from "64bit architecture" (but it seems they > no longer provide any 32bit architecture downloads (e.g. for Win32)) > > so in the long run, i think that 32bit architectures will no longer be > relevant on any download page (i guess the only 32bit architecture that > will stay relevant for some time is armv8; but there are no downloadable > binaries on any homepage anyhow; and a package manager like "apt" picks > the "correct" version of Pd anyhow) > > > i think one of the questions is, where the name will actually be exposed. > > - of course, the webpage (https://msp.ucsd.edu/, https://puredata.info/) > cou use whatever descriptive name to lure the people into downloading > the right package. > - personally I'm mostly concerned with package managers (and as said > above: all package managers I know of have a way to handle the > architecture (amd64, i386) more or less transparently) > - then there's the binary you run on your computer Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision pd?
>> On Mon, 2023-06-05 at 11:46 +0200, Miller Puckette wrote: >> Pdouble? > > Pd? pdpd? enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] Pd 0.54 macOS stuff etc?
Howdy all, if we are in a release cycle, is there anything major I can look at? I’m thinking of Tk 8.6.13 for macOS builds, etc. enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision pd?
I agree the “64” naming, while technically correct, will just get mixed up with
architecture.
Too bad “dp” is already used by pddp.
I now think of “wide” pd but that’s perhaps too general, although could be fun.
enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com
> On Jun 5, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:
>
> Message: 3
> Date: Mon, 5 Jun 2023 11:44:54 +0200
> From: IOhannes m zm?lnig
> To: pd-dev@lists.iem.at
> Subject: Re: [PD-dev] double precision pd?
> Message-ID: <0891ab25-d572-828b-881a-cef4cc65c...@iem.at>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>> On 6/4/23 17:22, Alexandre Torres Porres wrote:
>> well, great then, cause it's been merged :) time to get ready for double
>> precision finally then I guess! Really excited about it <3
>
>
> the other question that ought to answered is: how do we actually call it
> in order to prevent confusion?
>
> "Pd double precision" is a bit clumsy.
>
> "Pd64" is terser ("pd64.exe", "libpd64.dll"; and that's what I called
> the tentative double-precision packages for Debian/Ubuntu/... for now)
> but of course there might be some confusion with amd64/x86_64/arm64...
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling debug mode for GDB on MSYS2 MINGW64
I would also suggest putting important platform-specific stuff with the sources in msw/README.txt. > On May 19, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 3 > Date: Fri, 19 May 2023 09:17:57 +0200 > From: Pierre Mallard <mailto:mallard.pie...@gmail.com>> > To: Christof Ressi mailto:i...@christofressi.com>> > Cc: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Compiling debug mode for GDB on MSYS2 MINGW64 > Message-ID: ><mailto:CAKODt8xPxkv=mC9t9fU6LfY=bfoi651e55u5rotx73taxue...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hello Chris and everyone, > > Thanks for the trick, it could be nice to complete the wiki on > http://puredata.info/docs/developer/BuildingPd with at least your approach > (mine would require to patch msw/Makefile.am) > Let me know if it is worth it, I don't have an account there. > > Bye Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] problem loading tcl tk plugin with binary
I agree. If you just need access to the popup menu, you can support both old
versions and the new global popup by first checking the pd version or available
of .popup (ie. check if it exists) and use the one available to the version.
There are various examples of this in the Pd tcl sources, ie. checking Tcl/Tk
versions or checking if a name or variabel exists before creating or trying to
use it, etc.
I also agree about the issue: it's likely the plugin may be trying to grab
stuff that just isn; y there yet. I would move part of this setup stuff to
something later in the process, ie. perhaps a lazy-creation proc which gets the
plugin popup reference and sets the value from the global instance if it
doesn't exist yet.
> On May 15, 2023, at 10:08 AM, pd-dev-requ...@lists.iem.at wrote:
>
>> So, I'm not sure I get it but I'm assuming this won't be an issue in the
>> next version, right? Please confirm.
>
> what would "not be an issue"?
> with Pd-0.54 the ".popup" will not be created any more at all, so if
> your code depends on such an item, it will fail.
> otoh, Pd-0.54 will replace the ".popup" with a window-specific
> "${win}.popup". this window-specific item will not be created until the
> window is created, so if your code depends on such an item to exist at
> startup time, it is likely to fail as well.
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] branch names (was Re: figuring out how to get everything merged)
I'm fine with branching master, (hard) resetting back to a previous point, merging/cherry-picking portaudio fixes, tagging 0.53-2, then doing a force push. As long as everyone knows ahead of time, we can do a force pull afterwards. Yes, it's best avoided, but is sometimes be needed. Afterwards, maybe current development can be in the branch until ready, ie. feature/multi-channel or develop/0.54, etc? > On Feb 6, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Mon, 6 Feb 2023 09:44:36 +0100 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] branch names (was Re: figuring out how to get > everything merged) > Message-ID: <47a595e9-4e0a-12fb-1432-41803fc6c...@iem.at > <mailto:47a595e9-4e0a-12fb-1432-41803fc6c...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 2/5/23 22:37, Miller Puckette via Pd-dev wrote: >> Yep, I originally made a "0.53" branch but then messed it up so badly >> I had to start over - and thought it better to change the name to >> avoid confusion. > > i see. > it seems like the "avoid confusion" did not utterly succeed though ;-) Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] figuring out how to get everything merged
> on close inspection, it turns out that the portaudio/ directories in the > '0.53-2' branch and the 'master' branch are indeed different. > i don't know why and how they have been imported (presumably with the > 'portaudio/update.sh' script, but the > portaudio/portaudio/src/common/pa_gitrevision.h now shows 'unknown' > which is not very helpful) It looks like the script was not used nor was my update/portaudio branch merged which has the define set. The script indeed sets the PA_GIT_REVISION using the update_gitrevision.sh script in the PA repo. I had fixed several small issues with the script itself, mainly due to a file no longer being present in the new portaudio version which may have been why it wasn't used in the end. In any case, I made a small commit directly to the 0.53-2 branch which addresses this and should be pulled into master: dd20389559b3b293a1dd4fdc427f1881e3818bd3 ---- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)
Max (I think) had the suggestion of using established audio tech terms -> [snake~] and [breakout~] where "breakout" refers to a breakout box from a physical audio snake. It might translate a bit better than a non-word like "unsnake" ? You could take it further to [breakin~] / [breakout~] but I don't believe "breakin" is really used in the audio context, at least the part hat I deal with. For a single channel, [tap~] makes conceptual sense to me but then this is perhaps a different (water) metaphor? No matter what is chosen, it's nice to go through the options a this is one of these parts of the API that can't be (easily) changed later on. For my own projects, I offend agonize over the naming at the beginning. > On Jan 25, 2023, at 7:53 AM, pd-dev-requ...@lists.iem.at wrote: > > Message: 3 > Date: Tue, 24 Jan 2023 20:48:52 -0800 > From: Miller Puckette mailto:m...@ucsd.edu>> > To: Christof Ressi mailto:i...@christofressi.com>> > Cc: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, > preliminary support) > Message-ID: mailto:y9c0tctvcxwem...@ucsd.edu>> > Content-Type: text/plain; charset=iso-8859-1 > > OK... now I'm hesitating between "snake~ in", "snake~ out" and "snake~ tap" > or "join~", "split~", and "tap~"... > > Former is more colorful (and crowds the namespace less). Latter might be > easier for non-native English speakers to deal with? > > cheers > Miller Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)
Another option is an object like [clone] which instantiates for multichannel handling only... could simply be called [mc~] and take specific creation names for functionality, otherwise creates the objects for mc handling, so works like [text] etc: [mc 4 osc~] -> creates 4 [osc~] instances inside [mc pack 4] -> unpacks 4 channels [mc unpack] -> packs 4 channels [mc tap 1] -> taps single channel 1 out of the 4 channels ... > On Jan 23, 2023, at 6:33 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Mon, 23 Jan 2023 09:02:33 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: Roman Haefeli mailto:reduz...@gmail.com>> > Cc: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, > preliminary support) > Message-ID: ><mailto:caeasfmiwcapqn-4luijlmkt3kdvvpzliqsuqk4w4mtzd657...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > I actually do like pack~/unpack~ a lot, because they have control > counterparts and also MAX uses something similar but prepends 'mc.' to it, > so [mc.pack~] and [mc.unpack~] are exactly what [pack~] and [unpack~] do! > > On the other hand, if we really want to avoid this collision badly, maybe > we could use a similar convention to specify an object that is multichannel > aware, something quite new in the pd world. I'm not saying we should use > the same 'mc.' convention. I know using "." is not much common in the Pd > world, but in ELSE I use it and have plans to add many multichannel aware > externals that would make things simpler and while we don't have our > [clone] solution for internal and external objects, like a muti channel > [dac~] object called [dac.mc~]. I like it better that the mc comes later as > objects would be alphabetically next to their multichannel version. This > would also prevent people from thinking it's an external from Cyclone that > mimics the original. > > > So... what about [pack.mc~] and [unpack.mc~]? > > maybe just [packmc~] and [unpackmc~] as well... but I like "." > > cheers Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)
I was trying to think of a further biblical [moses] analogy, but I guess there is probably a [moses~] already. Maybe [cross~] / [uncross~] ala Ghostbusters... "don't cross the streams" > On Jan 23, 2023, at 11:05 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Mon, 23 Jan 2023 18:53:12 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: Miller Puckette mailto:m...@ucsd.edu>> > Cc: Roman Haefeli mailto:reduz...@gmail.com>>, > pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, > preliminary support) > Message-ID: ><mailto:caeasfmgjzmnqj9iapgmj7jned96ddh9vx0b2dwps1sv2-zw...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > I find snake~ and unsafe~ a bit weird but amusing, I kinda like idea of > typing that object name and read it in a patch Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Removing [output~]? (was [clone] with subpatches)
Looks good to me. It seems similar to the rjlib [soundinput] and [soundoutput] abstractions which I use with PdParty: > On Jan 20, 2023, at 1:09 AM, pd-dev-requ...@lists.iem.at wrote: > > This seems simple, better and is more versatile and seems like a good > candidate for a new Vanilla [output~] abstraction that is really useful for > day to day usage. See screenshot below and find the patch attached. Please > give me feedback to see if I'm going in the right direction. If it is ok I > will make a PR and update the documentation. > > > [image: Screen Shot 2023-01-19 at 21.07.18.png] Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] multichannel signals, preliminary support
Without reading your reply in depth, it calls to mind my feeling that it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala: [clone pd …] This is probably another discussion, however. enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com > On Jan 19, 2023, at 7:02 AM, Alexandre Torres Porres wrote: > > > but anyway, I have a few doubts how [clone] would deal with internals, and > this is just a rough idea so far, and we'll have to better discuss this when > time is right... > > for instance, how would someone deal with arguments? > > Like, I made a simple abstraction to mimic somewhat MAX's [mc.dac~], which > takes multichannel signals and distributes them from channel 1. > > In clone, I need a damn simple abstraction with [inlet~] going into [dac~ > $1], and I use the '-di' flag to distribute multichannel input and '-s 1' so > '$1' gets values starting from 1. It works great, I also have an argument in > [clone] for the number of abstractions that in this case represents maximum > channels. > > So, being able to call internal objects inside [clone] saves us the need to > write a simple abstraction for this or any other object, which is good, but > how would I be able to set the argument of [dac~] in [clone] and have it > receive the instance number? That's something to think about, because simply > calling "dac~" instead of an abstraction name doesn't or shouldn't do it. > > Now, I can and will gladly code an abstraction that mimics MAX's [mc.dac~] in > ELSE (actually I have already, just to test these things). The abstraction > uses [clone] internally and uses yet another abstraction with [dac~] inside, > so the user just needs to call the abstraction name. With what we have, > someone can make a library with all internals and whatever more externals > they like in a similar fashion. It's great that the doors are opened for this > and that we can go crazy. It would also be nice that we didn't have to worry > about this and have our "wrapper object". If not into [clone], maybe a new > object, why not call it [mc~]? I think such a new object is needed because > it might be hard to expand [clone] to do more things than it's doing. this > [mc~] object than takes object names as an argument, and further arguments > according to the objects argument. This [mc~] object would be similar to > [clone] and create inlets/outlets according to the given object name and we'd > have a way to use them to set all copies or each of them. > Maybe "mc.dac~" is a special case... let's think of a [lop~] object, we > wouldn't really need to specify "$1" as an argument... it doesn't make much > sense. It does make sense to maybe use a cutoff argument for all copies > though, so you could have [mc~ lop~ 500] and all signal inputs get filter at > 500hz. For [dac~], the special case, we could give it $1 as an argument and > it would mean instance number, and a similar flag '-s 1' could set it, so > we'd have [mc~ -s 1 dac~ $1]. > > well, I guess that's it, I'm tired and going to bed > > cheers and good night > > >> Em qua., 18 de jan. de 2023 às 11:45, Dan Wilcox >> escreveu: >> I can't answer you as I haven't looked at Miller's implementation. I can >> *imagine* that if [clone] is able to load an internal class then it follows >> it would be able to open an external class which is loaded. I didn't mean to >> imply that it can *now* but more than it *might* be able to if it can loaded >> internal objects. >> >>> On Jan 18, 2023, at 3:43 PM, Alexandre Torres Porres >>> wrote: >>> >>>> Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox >>>> escreveu: >>> >>>> Also similar to Miller's approach, there appears to be a way to load >>>> existing mono externals in the mc mechanism. So yeah, same problem, >>>> similar technical solution, different implementation. >>> >>> Hmm, I am still missing what is Pd's approach to load an existing external >>> into a mc mechanism... >>> >>> I'm understanding that [clone] may be able to load internal objects (and >>> abstractions of course) into a new multi-channel paradigm, but not >>> externals. Please enlighten me. >>> >>> cheers >> >> >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] multichannel signals, preliminary support
I can't answer you as I haven't looked at Miller's implementation. I can *imagine* that if [clone] is able to load an internal class then it follows it would be able to open an external class which is loaded. I didn't mean to imply that it can *now* but more than it *might* be able to if it can loaded internal objects. > On Jan 18, 2023, at 3:43 PM, Alexandre Torres Porres wrote: > > Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox <mailto:danomat...@gmail.com>> escreveu: > Also similar to Miller's approach, there appears to be a way to load existing > mono externals in the mc mechanism. So yeah, same problem, similar technical > solution, different implementation. > > Hmm, I am still missing what is Pd's approach to load an existing external > into a mc mechanism... > > I'm understanding that [clone] may be able to load internal objects (and > abstractions of course) into a new multi-channel paradigm, but not externals. > Please enlighten me. > > cheers Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] multichannel signals, preliminary support
> On Jan 18, 2023, at 2:41 AM, pd-dev-requ...@lists.iem.at wrote: > > "MC is not an entirely new API for MSP objects. Instead it is built on top > of the existing MSP API. (...) This name prefix / wrapper approach seems like an implicit way of what Miller is looking at doing more explicitly via [clone]. Either way, they have also avoided having to update each object directly. > so it seems they did not create new codes and new objects, just adapted, > and even made it possible for it to open a special help patch but it's all > the same object and you can use this API to generate externals - if I get > things correctly... Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation. I believe this doesn't require any changes in libpd, thankfully. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Send~ and receive does not allow you to change name with a symbol!
I was thinking the same. Also, if the concern is "too many dsp objects", put them in sub patches / abstractions and use [switch~] to turn them off. This is what I do in our spatialization server patches at work where there are 4 levels of channel routing between 64 objects on each level. For instance, if there are only 4 outputs, all the other outputs are "switched off." > On Jan 17, 2023, at 8:47 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 3 > Date: Tue, 17 Jan 2023 16:47:27 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: Christof Ressi mailto:i...@christofressi.com>> > Cc: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>, m...@ucsd.edu > <mailto:m...@ucsd.edu> > Subject: Re: [PD-dev] Send~ and receive does not allow you to change > name with a symbol! > Message-ID: ><mailto:CAEAsFmgfeWnJTG4o4k6mrpK-S=waz+3n4ok8c9wvypzxms6...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > so, [throw~] can set the destination, why not use it? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] multichannel signals, preliminary support
I'm fine with objects like [osc~] not being multichannel is there is an easy
way to parallelize / multiplex instances ... ie. clone. For consistency, one
might want the Max approach of providing alternate versions of *all* dip
objects, but if that's too much code overhead and we can concentrate this into
clone or a similar object, it makes sense to me.
>> Incidentally, now I think the word "distribute" is ambiguous - does anyone
>> have a better word for packing/unpacking on way in and out of clones?
>>
>
> fan-in/fan-out? ('fi', 'fo')
I also thought of "fan in" and "fan out" ... probably to the consternation of
IOhannes who added the "triggerize" feature. ;)
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
[PD-dev] mac-dist-helper
Howdy all, I've been working on a single solution for creating distribution packages for macOS which automates the whole code signing and notarization process. What I have so far is a makefile inspired by pd-lib-builder which you can drop into a project and configure with only a few variables: https://github.com/zkmkarlsruhe/mac-dist-helper <https://github.com/zkmkarlsruhe/mac-dist-helper> I also have some hello world examples for a Cocoa app, openFrameworks app, console program, and Pure Data external: https://github.com/zkmkarlsruhe/mac-dist-helper-examples <https://github.com/zkmkarlsruhe/mac-dist-helper-examples> So far, I am able to build and package all 4 examples into dmg files which I can AirDrop to a second macOS system and run without warnings, errors, or right-click overrides. ---- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] release pd 0.52 update?
(Whoops, sending again with correct subject line) So far, we have been merging simple fixes into the develop branch, but another approach could be to have two develop branches: * develop: merged things agreed upon for the next release, things which *may* need additional testing as we move forward * develop-stable: bugfixes only, as applied to the current release version For many projects which use git, the master/main branch would be a "develop-stable" and people would checkout releases based on tags. Then a develop branch would be stuff like new features and updates for the next version which would be merged to master/main later on. We have stayed out of touching the master branch since it would have conflicted with the original sourceforge git repository and only Miller touches it. Maybe this is no longer a requirement? > On Oct 15, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at > <mailto:pd-dev-requ...@lists.iem.at> wrote: > > Even though it's not considered correct behavior, I still find it less > problematic to fully commit to changes in the main branch than to try to > maintain long twisted chains of duplicate bugfixes in both master and in some > 0.52 branch - this didn't work out so well this time around (I cornered myself > into taking the GUI updates into a minor release) but, ouch, we all just have > to > deal with my 1970s-vintage coding skills :) Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-dev Digest, Vol 209, Issue 3
So far, we have been merging simple fixes into the develop branch, but another approach could be to have two develop branches: * develop: merged things agreed upon for the next release, things which *may* need additional testing as we move forward * develop-stable: bugfixes only, as applied to the current release version For many projects which use git, the master/main branch would be a "develop-stable" and people would checkout releases based on tags. Then a develop branch would be stuff like new features and updates for the next version which would be merged to master/main later on. We have stayed out of touching the master branch since it would have conflicted with the original sourceforge git repository and only Miller touches it. Maybe this is no longer a requirement? > On Oct 15, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Even though it's not considered correct behavior, I still find it less > problematic to fully commit to changes in the main branch than to try to > maintain long twisted chains of duplicate bugfixes in both master and in some > 0.52 branch - this didn't work out so well this time around (I cornered myself > into taking the GUI updates into a minor release) but, ouch, we all just have > to > deal with my 1970s-vintage coding skills :) Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tilde object rework ideas
Howdy Miller, Multi-channel will be very useful, especially in the context of some of the sound spatialization work we have used libpd for at ZKM. A good idea from Ableton/Max which we can profit from as well. :) I agree with the naming suggestion from IOhannes. The CoreAudio API also uses "frames" in it's AudioStreamBasicDescription struct: https://developer.apple.com/documentation/coreaudiotypes/audiostreambasicdescription <https://developer.apple.com/documentation/coreaudiotypes/audiostreambasicdescription> I don't mention CoreAudio to say we should slavishly copy it, but I find the API pretty well designed in abstraction and naming. I think "s_frames" would be equivalent to "mBytesPerFrame". > On Sep 2, 2022, at 9:36 AM, pd-dev-requ...@lists.iem.at wrote: > > apart from that: > probably "s_length" might be called "s_frames" as this seems to be the > less ambiguous term. > > and i would personally prefer "s_samplerate" and "s_channels". > that would make for an easy distinction: the abbreviated names "s_n" and > "s_sr" are the convoluted ones, whereas the long names have the data > you'd expect. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling fat external binaries for Mac OS X
Safest way is to statically link everything into the external itself. Yes, this makes it huge but that's the *safest* method. Next method is to bundle the libs *with* the external *and* modify the externals' lib search path (RPATH) to check a local location first so the system loader will find your dylibs. Both methods are what macOS .app bundles do: either statically link *or* ship the dylibs inside the bundle. That being said, if the libs require internal APIs which change between macOS versions, then you may have to consider separate builds. However, despite all of the FUD mostly from people who don't use the platform often, Apple clearly deprecates APIs long in advance. The only libs that are generally *safe* to link to across macOS versions are libraries included with the system such as libxml2... but I would say that is about the only C system lib that I have directly linked to in *any* software I have written for macOS, that is beyond the internal Obj-C / Swift frameworks. I generally recommend *against* asking users to install libs via Homebrew. macOS is not Linux and Homebrew is not apt. Homebrew is heavily oriented towards developers and lib versions change pretty dynamically. There is no guarantee the lib you linked again on your build machine will match that of whatever version of macOS & Homebrew a user has. I have tried this approach with macOS .app bundles at work and only run into problems. For Homebrew to be a viable option, the best way is to require users to install the libs via Homebrew and build the external themselves. This is basically what HB is designed for, however, I assume this is what you are trying to avoid. That same goes for trying to pull a dylib from Homebrew and bundling it within your .app. I only ran into problems with as well and have generally written scripts or Makefiles to build all of my dependencies manually for distribution. Linking to a static version *may* work, but you still may run into issues if you require a *specific* version of the lib. > On Jun 16, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Would it be better for externals shipping with local dependencies to > provide them as fat binaries? For externals using localdeps I use > separate non-fat files, because they both link to different hard-coded > paths. I wouldn't how to do it differently. > > Is there a best way for shipping externals with local dependencies? If > yes, which is it? > > Roman Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling fat external binaries for Mac OS X
In my opinion (and experience), it's easier to make a fat lib. This is how most things are distributed on the platform moving forward. Technically, providing the arches as separate files should be possible but the question comes down to naming and/or separating the distribution in such a way that the system lib loading can find them correctly. With a fat lib build, you don't have to worry about it. I have honestly never bothered to figure out the separate arch, separate lib approach beyond major differences of OS versions ie. macOS 10.6 - 10.9, macOS 10.10+, etc. > On Jun 15, 2022, at 1:32 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Wed, 15 Jun 2022 13:32:09 +0200 > From: Roman Haefeli mailto:reduz...@gmail.com>> > To: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X > Message-ID: <mailto:ce868065d84420fd1d5115a34b0f433ba0a82d70.ca...@gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2022-06-15 at 12:53 +0200, Dan Wilcox wrote: >> >>> On Jun 15, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at >>> <mailto:pd-dev-requ...@lists.iem.at> wrote: >>> >>> Message: 1 >>> Date: Tue, 14 Jun 2022 14:23:16 +0200 >>> From:?reduz...@gmail.com <mailto:?reduz...@gmail.com> >>> To:?pd-dev@lists.iem.at <mailto:?pd-dev@lists.iem.at> >>> Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X >>> Message-ID: >>> <3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.ca...@gmail.com >>> <mailto:3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.ca...@gmail.com>> >>> Content-Type: text/plain; charset="UTF-8" >>> >>> On Wed, 2022-06-08 at 20:04 +0200, Dan Wilcox wrote: >>>> You can simply pass in the arches you want using the "arch" >>>> makefile >>>> variable: >>>> >>>> make arch="x86_64 arm64" >>> >>> That's cool to know. In the case of purest_json, I believe it ships >>> with other dependencies (libjson?) and if those come from homebrew, >>> they're probably not fat. Is my assumption correct, that a fat >>> binary >>> would have to link to fat binary?? >> >> I don't believe so. I think (not 100%) the system lib loading >> mechanism just needs to find the lib *and* have the right arch. I >> don't believe it matters if the lib is fat or not. >> > > Thanks for the clarification. The interesting question (to me at least) > is: If I want to support both archs, does the linked library need to be > fat, or can I link to two separate files per dependency? If I can't > link to different files for different archs, this means there is no > other way for maintaining support of both archs than to link to a fat > library. > > Roman Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling fat external binaries for Mac OS X
> On Jun 15, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Tue, 14 Jun 2022 14:23:16 +0200 > From: reduz...@gmail.com <mailto:reduz...@gmail.com> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X > Message-ID: <3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.ca...@gmail.com > <mailto:3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.ca...@gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2022-06-08 at 20:04 +0200, Dan Wilcox wrote: >> You can simply pass in the arches you want using the "arch" makefile >> variable: >> >> make arch="x86_64 arm64" > > That's cool to know. In the case of purest_json, I believe it ships > with other dependencies (libjson?) and if those come from homebrew, > they're probably not fat. Is my assumption correct, that a fat binary > would have to link to fat binary? I don't believe so. I think (not 100%) the system lib loading mechanism just needs to find the lib *and* have the right arch. I don't believe it matters if the lib is fat or not. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling fat external binaries for Mac OS X
In double-checking, posts like the following make me think that Xcode 9.4 is the last version which supports compiling for i386: https://developer.apple.com/forums/thread/108704 <https://developer.apple.com/forums/thread/108704> This would make your 32 bit setup require macOS 10.14 + Xcode 9.4. To clarify, I added Alex in CC. Alex: What is your current build setup (OS and Xcode version) for building fat libs with 32 bit Intel (i386) for distribution? > On Jun 8, 2022, at 8:04 PM, Dan Wilcox wrote: > > As to which versions of macOS (that's the official name for some years now) > to build on, I believe you can still build the i386 arch with Xcode on macOS > 10.15, so judging from the following it may be Xcode 11 or 12: > https://xcodereleases.com <https://xcodereleases.com/>. I think Alex Porres > is using this set up, so maybe he can chime in with his combo of OS and > Xcode. The irony is that you can't run the 32 bit arch on 10.15, but at least > you can build for it. Xcode on macOS 11 (version after 10.15) only allows for > building x64_64 and arm64. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Compiling fat external binaries for Mac OS X
You can simply pass in the arches you want using the "arch" makefile variable: make arch="x86_64 arm64" For example: danomatika@danomatika helloworld % make arch="x86_64 arm64" info: using Makefile.pdlibbuilder version 0.6.0 info: using Pd API /Applications/Pd-0.52-2.app/Contents/Resources/src/m_pd.h info: making target all in lib helloworld info: making helloworld.o in lib helloworld cc -DPD -I "/Applications/Pd-0.52-2.app/Contents/Resources/src" -DUNIX -DMACOSX -I /sw/include-Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch x86_64 -arch arm64 -mmacosx-version-min=10.6 -o helloworld.o -c helloworld.c info: linking objects in helloworld.pd_darwin for lib helloworld cc -undefined suppress -flat_namespace -bundle -arch x86_64 -arch arm64 -mmacosx-version-min=10.6 -o helloworld.pd_darwin helloworld.o -lc info: target all in lib helloworld completed danomatika@danomatika helloworld % file helloworld.pd_darwin helloworld.pd_darwin: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64] [arm64:Mach-O 64-bit bundle arm64] helloworld.pd_darwin (for architecture x86_64): Mach-O 64-bit bundle x86_64 helloworld.pd_darwin (for architecture arm64): Mach-O 64-bit bundle arm64 As to which versions of macOS (that's the official name for some years now) to build on, I believe you can still build the i386 arch with Xcode on macOS 10.15, so judging from the following it may be Xcode 11 or 12: https://xcodereleases.com <https://xcodereleases.com/>. I think Alex Porres is using this set up, so maybe he can chime in with his combo of OS and Xcode. The irony is that you can't run the 32 bit arch on 10.15, but at least you can build for it. Xcode on macOS 11 (version after 10.15) only allows for building x64_64 and arm64. I did add an "automatic" fat lib checker which determines which arch are available for the Xcode version but it's sitting in a PR right now. IN the end, I think I agree with IOhannes that it's maybe better to document and ask the user to set the required arch manually. It certainly keeps things simpler to maintain. The readme should probably be updated with this info as these questions keep resurfacing. > On Jun 8, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Wed, 8 Jun 2022 01:18:39 +0200 > From: Thomas Mayer mailto:tho...@residuum.org>> > To: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] Compiling fat external binaries for Mac OS X > Message-ID: <7fd6ada6-3f36-316b-9000-30e0cd641...@residuum.org > <mailto:7fd6ada6-3f36-316b-9000-30e0cd641...@residuum.org>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > I am currently working on the last steps for releasing a new version of > PuREST JSON. > > My main concern is now building fat binaries for Mac OS X. > > When I look at the list at the different versions for 0.52-2 at > https://puredata.info/downloads/pure-data > <https://puredata.info/downloads/pure-data> there is a version labeled "M1 > and Intel/64bit". I guess, I should link to it. > > Is there any environment variable I have to set for building building? > > I am using the current master version of pd-lib-builder, and I do not > see any reference to M1 in the block there: > https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6fe92bcdedd7b44/Makefile.pdlibbuilder#L506 > > <https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6fe92bcdedd7b44/Makefile.pdlibbuilder#L506> > > Also, what should be in the filename for deken zips? > > Any other version of Mac OS X that I should compile the external as > well, since there are downloads for 32 and 64 bit Intel as well? > Especially, because the 64 bit version is labeled as OS X 10.7 - 10.9. > > The question about filename of deken zips applies to these as well. > > Thanks, > Thomas > -- > "As long as people kept worrying that the machines were taking over, > they wouldn't notice what was really happening. Which was that the > programmers were taking over." (Robert Anton Wilson - The Homing Pidgeons) > http://www.residuum.org/ <http://www.residuum.org/> Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] embedding macOS libraries (was Re: building fluidsynth~)
Should we consider having a copy of the old or your new script in a canonical repo such as with pd-lib-builder? Or it's own GH repo? Something similar could be a makefile or script to help automate the whole macOS code signing process as well. > On May 4, 2022, at 8:32 AM, pd-dev-requ...@lists.iem.at wrote: > > On 5/4/22 03:47, Sebastian Shader via Pd-dev wrote: >> for a simpler example of?the changing-rpath mehod, purest_json also >> distributes shared libs on osx (recursively through the >> dependencies)?https://github.com/residuum/PuRestJson >> <https://github.com/residuum/PuRestJson> > > probably simpler. > but from what i've seen so far, this is just another copy (of with some > minor modifications) of the original embed-OSX-libraries script that > hans-christof wrote two decades ago. > > my script (that roman mentioned) [1] for the iem-ci (where it is stress > tested wih all those iem externals, including beasts like Gem), is also > based on that original embed-OSX-libraries script, but has seen a number > of improvements over the last 20 years, like being independent of > homebrew (think macports; or your own personal package manager) or > having a consistent interface across various platforms (i have multiple > scripts [2] for windows/macOS/linux, but they all share the same interface). Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] codesigning externals (was Re: building fluidsynth~)
This is correct. I added it to the Pd app bundle entitlements to get rid of the error dialog for (older) externals on macOS 10.15, I believe: https://github.com/pure-data/pure-data/blob/master/mac/stuff/pd.entitlements <https://github.com/pure-data/pure-data/blob/master/mac/stuff/pd.entitlements> https://eclecticlight.co/2021/01/07/notarization-the-hardened-runtime/ <https://eclecticlight.co/2021/01/07/notarization-the-hardened-runtime/> If you start signing dynamic libs, I think you also need to set the min deployment target to 10.9 or above, at least for apps with a "hardened run-time" but I'm not sure if Pd does since we are (re)using the Wish app from the Tk build process. (I *think* it is as it is enabled during the code sign steps which apply the entitlements?.) The security settings like these are much more obvious when making a more "native app" via Xcode but less so when building on the command line. In any case, I did a quick search and found the following: https://developer.apple.com/forums/thread/130065 <https://developer.apple.com/forums/thread/130065> https://developer.apple.com/documentation/security/hardened_runtime <https://developer.apple.com/documentation/security/hardened_runtime> etc... (Sorry for not being the authority on this. I honestly try to write scripts for this so I can flush my memory every time I deal with code signing.) > On May 4, 2022, at 8:32 AM, pd-dev-requ...@lists.iem.at wrote: > > i guess that while Pd has the permission to load *unsigned* externals, > macOS still refuses to load *signed* externals with an invalid signature. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building fluidsynth~ (was: building fluid~ on Linux)
(fixing subject line I forgot in previous email) I forgot to mention that my response was directed more for macOS and possibly Windows where asking people to use a package manager is a bit more of a stretch as opposed to Linux. In general, dependent libs are packaged with the program itself and sometimes dynamic linking can be problematic, ie. on macOS you often have to (re)set the rpath in a built lib. That dance in avoided by simply statically linking at the expense of binary size. I'm not saying it's the best solution, but it may be more maintainable and usable in the case of a dynamically-loaded Pd external. OTOH I believe GEM provides dynamic libs along with the externals on macOS but this most probably requires fiddling with the rpath, basically overriding the search path for the lib to it's found in a different, non-system location. For Windows, if I recall correctly, you generally just need to place the dlls next to whatever is using them. As for mixing static and dynamic linking, I believe that's not a problem as long as the dynamic libs are found. > On May 4, 2022, at 12:06 AM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Tue, 03 May 2022 23:53:26 +0200 > From: Roman Haefeli mailto:reduz...@gmail.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Pd-dev Digest, Vol 204, Issue 11 > Message-ID: <0ab1d4fbc2d4d0f609870c1b5f06178a0fdc6a23.ca...@gmail.com > <mailto:0ab1d4fbc2d4d0f609870c1b5f06178a0fdc6a23.ca...@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > On Tue, 2022-05-03 at 23:29 +0200, Dan Wilcox wrote: >> My two cents: I have tried in the past to bundle dynamic libs >> generated/downloaded by homebrew into app distributions to run on >> other systems and *always* run into problems. It hs always been >> simpler to statically link, either to the home-brew lib or by >> building the lib(s) myself using a script or makefile. For longer >> term projects, I generally prefer to automate building the lib >> statically then linking it directly into the program. > > THanks for your insight. > > Please forgive the noob question, but do I have static builds of all > the dependencies available for that to work? And if I don't, do I have > to compile the dependencies and make sure they're built statically > (which isn't always obvious to me with the various build systems). > > Roman Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-dev Digest, Vol 204, Issue 11
My two cents: I have tried in the past to bundle dynamic libs generated/downloaded by homebrew into app distributions to run on other systems and *always* run into problems. It hs always been simpler to statically link, either to the home-brew lib or by building the lib(s) myself using a script or makefile. For longer term projects, I generally prefer to automate building the lib statically then linking it directly into the program. > On May 3, 2022, at 8:57 PM, pd-dev-requ...@lists.iem.at wrote: > >>> I often find things are a bit easier on Linux, but that's what I >>> got >>> accustomed to. In the case of the fluidsynth~ external, using the >>> dynamic libraries from my distro (Ubuntu 22.04) doesn't seem >>> practical, >>> as libfluidsynth.so.3 links against virtually half the system. >>> After >>> executing the localdep script, I end up with 53 *.so files. Most of >>> them aren't actually used when libfluidsynth is used for the pd >>> external. Creating a more stripped down build of libfluidsynth >>> probably >>> would make sense here. > >> Cool, but how? :)? > > By building fluidsynth from source with the minimal set of configure > flags required for the pd external. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] how to compile externals for apple silicon?
Are you building with the min macos version flag set to 10.9 or higher? I think that is required to avoid the dialog when loading. enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com > On May 1, 2022, at 6:14 PM, Alexandre Torres Porres wrote: > > > Thanks Dan. I have a developers account, that's how I got XCode 12.4 - you > taught me that a couple of years ago ;) - and I linked to an apple site that > said it'd be able to compile for arm but it failed. One way or another, I > think I can give this up as I'm not sure my solution is finding a system > older than monterey to build for mojave to monterey and offer a fat binary > for intel and arm. > > Regarding building a 64 bit intel external that works in OSes from at least > mojave to monterey, this is already possible when building in mojave, but > newer versions of macOS will complain it ain't safe and it's a hassle to > allow it to load (I mentioned this in the other "building fluidsynth~" > thread). It seems better to just solve this issue, but even so, I have other > issues I need to figure out as I also mentioned in the other thread. > > Thanks again! > >> Em dom., 1 de mai. de 2022 às 12:56, Dan Wilcox >> escreveu: >> Honestly, I don't know. I've not looked into specific versions of which >> Xcode can compile what. I basically just follow the normal upgrade cycle of >> keeping Xcode up to date with whatever macOS version I currently have. I >> don't care to spend much more headspace on it than that! >> >> At some point, I couldn't build for i386 (I think some version of Xcode 10) >> so I removed building for x86_64. The same happened when I upgraded to some >> version of Xcode 12, I think, which included the SDK which includes compiler >> support for arm64. >> >> I assumed I couldn't build i386 some time when I was on macOS 10.15 but I >> didn't write it down. If you want to spend the time for an answer, probably >> read through the Xcode release notes: >> https://developer.apple.com/documentation/xcode-release-notes. >> >> If you want to download and try different Xcode version, there is a handy >> site to the downloads provided by the Apple Developer portal: >> >> https://xcodereleases.com >> >> You will need a developer account to access them. >> >>> On May 1, 2022, at 5:30 PM, Alexandre Torres Porres >>> wrote: >>> >>>> Em dom., 1 de mai. de 2022 às 04:42, Dan Wilcox >>>> escreveu: >>> >>>> You cannot build for i386. Support for that arch was famously removed in >>>> macOS 10.15 and those versions of Xcode which use its SDK, probably >>>> version 10 or so. Modern fat libs arm64 and x86_64. >>> >>> Damn, double checked and tested. Using XCode 12.4 on Catalina, I was able >>> to compile else with a fat binary for both 32/64 bits, see --> >>> https://github.com/porres/pd-else/issues/1241#issuecomment-1114263525 >>> >>> Back on Mojave, I downloaded 0.52-2 32 bits and tested the externals, it >>> worked! >>> >>> I can see it shouldn't, it really makes sense it should build or work, I >>> should have known better and expected a failure and be amazed when it first >>> compiled because it doesn't make sense, but it's happening. >>> >>> Also, I can't build for arm64... >>> >>> Anyone can help me solve the mistery? >>> >>> screenshot to try to prove i'm not crazy >>> >>> <166152846-b962d8e0-6fc7-461c-a1f0-e8e04c0d9682.png> >>> >>>> >>>> enohp ym morf tnes >>>> --- >>>> Dan Wilcox >>>> danomatika.com >>>> robotcowboy.com >>>> >>>> >>>>>> On May 1, 2022, at 2:51 AM, Alexandre Torres Porres >>>>>> wrote: >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Em qui., 10 de mar. de 2022 às 19:57, Dan Wilcox >>>>>> escreveu: >>>>>> I have a fork of pd-lib-builder which supports arm64 & universal builds >>>>>> on macOS. The PR has been sitting for some time but we have been using >>>>>> it successfully for a few projects for some time now: >>>>>> >>>>>> https://github.com/pure-data/pd-lib-builder/pull/69 >>>>>> >>>>>> To build for arm64, you need a new enough Xcode (12.2 I believe) and >>>>>> th
Re: [PD-dev] [PD] how to compile externals for apple silicon?
Honestly, I don't know. I've not looked into specific versions of which Xcode can compile what. I basically just follow the normal upgrade cycle of keeping Xcode up to date with whatever macOS version I currently have. I don't care to spend much more headspace on it than that! At some point, I couldn't build for i386 (I think some version of Xcode 10) so I removed building for x86_64. The same happened when I upgraded to some version of Xcode 12, I think, which included the SDK which includes compiler support for arm64. I assumed I couldn't build i386 some time when I was on macOS 10.15 but I didn't write it down. If you want to spend the time for an answer, probably read through the Xcode release notes: https://developer.apple.com/documentation/xcode-release-notes <https://developer.apple.com/documentation/xcode-release-notes>. If you want to download and try different Xcode version, there is a handy site to the downloads provided by the Apple Developer portal: https://xcodereleases.com <https://xcodereleases.com/> You will need a developer account to access them. > On May 1, 2022, at 5:30 PM, Alexandre Torres Porres wrote: > > Em dom., 1 de mai. de 2022 às 04:42, Dan Wilcox <mailto:danomat...@gmail.com>> escreveu: > You cannot build for i386. Support for that arch was famously removed in > macOS 10.15 and those versions of Xcode which use its SDK, probably version > 10 or so. Modern fat libs arm64 and x86_64. > > Damn, double checked and tested. Using XCode 12.4 on Catalina, I was able to > compile else with a fat binary for both 32/64 bits, see --> > https://github.com/porres/pd-else/issues/1241#issuecomment-1114263525 > <https://github.com/porres/pd-else/issues/1241#issuecomment-1114263525> > > Back on Mojave, I downloaded 0.52-2 32 bits and tested the externals, it > worked! > > I can see it shouldn't, it really makes sense it should build or work, I > should have known better and expected a failure and be amazed when it first > compiled because it doesn't make sense, but it's happening. > > Also, I can't build for arm64... > > Anyone can help me solve the mistery? > > screenshot to try to prove i'm not crazy > > <166152846-b962d8e0-6fc7-461c-a1f0-e8e04c0d9682.png> > > > enohp ym morf tnes > --- > Dan Wilcox > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > >> On May 1, 2022, at 2:51 AM, Alexandre Torres Porres > <mailto:por...@gmail.com>> wrote: >> >> >> >> >> >> Em qui., 10 de mar. de 2022 às 19:57, Dan Wilcox > <mailto:danomat...@gmail.com>> escreveu: >> I have a fork of pd-lib-builder which supports arm64 & universal builds on >> macOS. The PR has been sitting for some time but we have been using it >> successfully for a few projects for some time now: >> >> https://github.com/pure-data/pd-lib-builder/pull/69 >> <https://github.com/pure-data/pd-lib-builder/pull/69> >> >> To build for arm64, you need a new enough Xcode (12.2 I believe) and that's >> it. You can cross-compile on an x86_64 machine for arm64 and vice-versa. >> >> So, I now have a partition with Catalina (10.15.7) and Xcode 12.4, which is >> the last version catalina accepts. >> >> According to https://developer.apple.com/pt/support/xcode/ >> <https://developer.apple.com/pt/support/xcode/> I believe 12.1 could have >> been possible already. 12.5 needs Big Sur. Here's a table from the link >> >> Versão do Xcode Sistema operacional mínimo necessário SDK >> Arquitetura Destinos de implantação Simulador Swift >> >> Xcode 12.4 macOS Catalina 10.15.4 (Mac com processador Intel) >> >> macOS Big Sur 11 >> (Mac com Apple Silicon) iOS 14.4 >> macOS 11.1 >> tvOS 14.3 >> watchOS 7.2 >> DriverKit 20.2 x86_64 >> armv7 >> armv7s >> armv7k >> arm64 >> arm64e >> arm64_32 iOS 9-14.4 >> iPadOS 13-14.4 >> macOS 10.9-11.1 >> tvOS 9-14.3 >> watchOS 2-7.2 >> DriverKit 19-20.2 >> >> It says it can build for 'arm64' alright, but I tried creating a fat binary >> for both intel and M1 as I was doing in my monterey partition and didn't >> succeed. I'm using pd-lib-builder, verdsion 6.0, so I did: >> >> make install objectsdir=../ arch="i386 x86_64" extension=d_fat and that >> works just fine >> >> but... >> >> make install objectsdir=../ arch="arm64 x86_64" extension=d_fat fails >> miserably, this is what I get >> >> >> /Libr
Re: [PD-dev] [PD] how to compile externals for apple silicon?
By "modern" I was referring to the architectures, not the lib bundling mechanism. I know I've mentioned it before and you bring it up again: it's probably possible to create a single fat lib with ppc, i386, x86_64, and arm64. This is, however, at best an academic exercise. > On May 1, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Sun, 1 May 2022 10:52:17 +0200 > From: IOhannes m zm?lnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? > Message-ID: <2a870fec-b81f-75d0-81e3-5a59462e2...@iem.at > <mailto:2a870fec-b81f-75d0-81e3-5a59462e2...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 5/1/22 09:42, Dan Wilcox wrote >> You cannot build for i386. Support for that arch was famously removed in >> macOS 10.15 and those versions of Xcode which use its SDK, probably version >> 10 or so. Modern fat libs arm64 and x86_64. > > just to add a bit of confusion... > > technically, i think there's no difference between a "modern" and a > "legacy" fat lib: it's a file format that can contain multiple > architectures. > there's absolutely nothing keeping you from having a fat binary that > contains arm64, x86_64, i386 and ppc. > > the only obstacle is, that there is no compiler that can create binaries > for all of these architectures. > but you can create the binaries on multiple systems (different macOS/OSX > versions; different Xcode installations) and then use 'lipo' to merge > the different single-arch binaries into a single fat one. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] how to compile externals for apple silicon?
You cannot build for i386. Support for that arch was famously removed in macOS 10.15 and those versions of Xcode which use its SDK, probably version 10 or so. Modern fat libs arm64 and x86_64. enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com > On May 1, 2022, at 2:51 AM, Alexandre Torres Porres wrote: > > > > > >> Em qui., 10 de mar. de 2022 às 19:57, Dan Wilcox >> escreveu: >> I have a fork of pd-lib-builder which supports arm64 & universal builds on >> macOS. The PR has been sitting for some time but we have been using it >> successfully for a few projects for some time now: >> >> https://github.com/pure-data/pd-lib-builder/pull/69 >> >> To build for arm64, you need a new enough Xcode (12.2 I believe) and that's >> it. You can cross-compile on an x86_64 machine for arm64 and vice-versa. > > So, I now have a partition with Catalina (10.15.7) and Xcode 12.4, which is > the last version catalina accepts. > > According to https://developer.apple.com/pt/support/xcode/ I believe 12.1 > could have been possible already. 12.5 needs Big Sur. Here's a table from the > link > > Versão do Xcode Sistema operacional mínimo necessário SDK > Arquitetura Destinos de implantação Simulador Swift > > Xcode 12.4macOS Catalina 10.15.4 (Mac com processador Intel) > > macOS Big Sur 11 > (Mac com Apple Silicon) iOS 14.4 > macOS 11.1 > tvOS 14.3 > watchOS 7.2 > DriverKit 20.2x86_64 > armv7 > armv7s > armv7k > arm64 > arm64e > arm64_32 iOS 9-14.4 > iPadOS 13-14.4 > macOS 10.9-11.1 > tvOS 9-14.3 > watchOS 2-7.2 > DriverKit 19-20.2 > > It says it can build for 'arm64' alright, but I tried creating a fat binary > for both intel and M1 as I was doing in my monterey partition and didn't > succeed. I'm using pd-lib-builder, verdsion 6.0, so I did: > > make install objectsdir=../ arch="i386 x86_64" extension=d_fat and that works > just fine > > but... > > make install objectsdir=../ arch="arm64 x86_64" extension=d_fat fails > miserably, this is what I get > > > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/cdefs.h:807:2: > error: Unsupported architecture > #error Unsupported architecture > > What should I do? > > My attempt here is to be able to build a binary for fluidsynth~ that works > for a wide range of OSes > > thanks > cheers > >> >>> On Mar 10, 2022, at 11:30 PM, pd-dev-requ...@lists.iem.at wrote: >>> >>> Message: 2 >>> Date: Thu, 10 Mar 2022 17:57:23 -0300 >>> From: Alexandre Torres Porres >>> To: Sebastian Shader >>> Cc: "pd-dev@lists.iem.at" >>> Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? >>> Message-ID: >>> >>> Content-Type: text/plain; charset="utf-8" >>> >>> I guess I can install catalina on a partition, but I was hoping to use >>> pdlibbuilder in an easy way, is it possible? >> >> >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] error missing in Pd 0.52
You missed the discussion because it took place in libpd-land:
https://github.com/libpd/libpd/issues/336
<https://github.com/libpd/libpd/issues/336>
It was not a decision taken lightly, but it's necessary as Pd's previous
"error()" could conflict with libc "error()". The replacement already existed
for sometime, so changing calls to "error(...)" with "pd_error(0, ...)" should
be equivalent and not break the external in old versions of Pd.
> On Apr 29, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:
>
> Message: 2
> Date: Fri, 29 Apr 2022 09:51:48 +0200
> From: Roman Haefeli mailto:reduz...@gmail.com>>
> To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: [PD-dev] error missing in Pd 0.52
> Message-ID: <96224f3ab47171eff50b17d1507974c6d8b13fd5.ca...@gmail.com
> <mailto:96224f3ab47171eff50b17d1507974c6d8b13fd5.ca...@gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> Hey all
>
> Since 0.52, compiling of some externals fails with an error like:
>
> ~~
> binfile.c:103:9: error: implicit declaration of function 'error' is invalid
> in C99 [-Werror,-Wimplicit-function-declaration]
>error("binfile: Could not create...");
> ~~~
>
> In 0.51-4, the error function was still defined in m_pd.h. Was 'error'
> deprecated in favor of pd_error?
>
> Sorry, if I missed the related discussions, but I feel introducing
> breaking changes in Pd is generally not done lightly. And I found
> similar issues in active developments like aoo, so I'm probably not the
> only one having missed this.
>
> Roman
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
[PD-dev] mrpeach midifile maintenance
Howdy all, there appears to be some questions/issues regarding mrpeach [midifle] on GitHub: https://github.com/pd-externals/mrpeach/issues <https://github.com/pd-externals/mrpeach/issues> I use the object quite a bit but don't have time to look into this as I want to finalize some libpd & PdParty stuff. Maybe other users of this object can pitch in? ---- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion double-precision file extension)
Mmmm I wouldn't make this assumption. By default, the libpd repo makefile throws in LIBDL when linking on platforms that support it, so desktop apps *could* support loading externals. I for one, however, have not relied on this myself, but I could imagine *someone, somewhere* does? > On Apr 4, 2022, at 3:01 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Mon, 4 Apr 2022 15:00:52 +0200 > From: Christof Ressi mailto:i...@christofressi.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] PDINSTANCE for Pd (was Re: call for discussion > double-precision file extension) > Message-ID: <0861a01f-14da-166c-df62-d8cebe2ed...@christofressi.com > <mailto:0861a01f-14da-166c-df62-d8cebe2ed...@christofressi.com>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > >> I was thinking to a way for the transition: we could: >> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_* >> replacement? macros accordingly), >> - export "hidden" globals s_* >> - initialize pd_maininstance pd_s_* fields to the global versions. > Yes, this would work. Of course, it would be an ABI break for > multi-instance libpd, but I think it would be justified. I guess libpd > users rarely rely on pre-build externals, and even if they do, I think > it's ok to ask them to recompile. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] call for discussion double-precision file extension
I lean much more on the side that PDINSTANCE is a low-level, per project compile option and not general-purpose. If you are using libpd, then your environment is a bit more custom anyway. > On Mar 30, 2022, at 5:40 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Wed, 30 Mar 2022 16:06:23 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] call for discussion double-precision file > extension > Message-ID: <3a9d2e07-a831-eb18-7797-5ff5b191e...@iem.at > <mailto:3a9d2e07-a831-eb18-7797-5ff5b191e...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 3/29/22 20:26, Sebastian Shader via Pd-dev wrote: >> >> I wonder if anything should be considered for multi-instance support as well >> (externals compiled w/ PDINSTANCE) > > good question. > > afaict, there are no plans to ever ship binaries Pd with PDINSTANCE=1 > (but i have no idea, really). > > can we expect developers of PDINSTANCE-enabled (lib)Pds to also provide > the binaries for the extrenals? > i guess it would be nice if you (as a patch-developer with a > compiler-allergy) could just install whatever externals you want to be > included with your camomille-based VST plugin. > > gfmdras > IOhannes Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd 0.52-2 release plan
I think it's worth documenting it as a debuting tool, since that's what it's there for, as far as I can tell for Miller's response. > On Mar 24, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Wed, 23 Mar 2022 17:39:36 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: Miller Puckette mailto:m...@ucsd.edu>> > Cc: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] pd 0.52-2 release plan > Message-ID: ><mailto:CAEAsFmhxRSpD5pLg0TBjxH08Ugo1zw7LQV2jv=+1arddba0...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Not sure it's worth documenting then... I should test and see it for myself > how it works so I actually get it. > > keeping it as a hidden feature for now. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] how to compile externals for apple silicon?
I have a fork of pd-lib-builder which supports arm64 & universal builds on macOS. The PR has been sitting for some time but we have been using it successfully for a few projects for some time now: https://github.com/pure-data/pd-lib-builder/pull/69 <https://github.com/pure-data/pd-lib-builder/pull/69> To build for arm64, you need a new enough Xcode (12.2 I believe) and that's it. You can cross-compile on an x86_64 machine for arm64 and vice-versa. > On Mar 10, 2022, at 11:30 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Thu, 10 Mar 2022 17:57:23 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: Sebastian Shader mailto:sebfumas...@aol.com>> > Cc: "pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>" <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? > Message-ID: ><mailto:caeasfmiupgiiewwpvm11eyy6ke6bdgiwfqfa8pbvpbjtuao...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > I guess I can install catalina on a partition, but I was hoping to use > pdlibbuilder in an easy way, is it possible? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Why not use portaudio per default?
It's actually relatively easy, but very verbose since running configure then runs the dependent lib configures as well. You just have to point the configure script to the subdirectory with another configure script. I have a couple projects which use autotools and rely on a couple custom libraries which also use autotools. You just pass the subdirectories via AC_CONFIG_SUBDIRS: https://github.com/danomatika/joyosc/blob/master/configure.ac#L85 <https://github.com/danomatika/joyosc/blob/master/configure.ac#L85> But in the end, I plan to simplify this layout and remove the need for this arrangement in the future. > On Jan 22, 2022, at 6:57 PM, pd-dev-requ...@lists.iem.at wrote: > > Since we build the sources ourselves, as you have noted, it probably > makes sense to keep them in our repo as well. I don't even know how to > properly integrate an automake project... Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Why not use portaudio per default?
Also, I would be happy to see integrating more modern backends for Windows, ala the portaudio waspi implementation. We don't build it for now as I only kept the those APIs which we were building at the time when we did the autotools overhaul. Just modify the portaudiuo/update.sh script to include those .c files for the additional implementations and add them to portaudio/Makefile.am. Also, since the portaudio configure script was very old and delicate, especially on macOS, we opted to build portaudio and portmidi as convenience libs ourselves. This may have improved on the portaudio side, but I ran into many problems with the portaudio configure failing while building the c files directly worked. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Why not use portaudio per default?
I agree with IOhannes in that it's an advantage to keep all of the sources together. Besides, we also only include those portaudio sources we actually need and build them manually, ie. as a static convince lib via autotools etc. When I helped with overhauling the autotools build some years ago, I kept that aspect as an expedient, but I think it's still a good practice in that Github, at the time, didn't actually check out the sources for submodules when downloading a zip or tarball via the online interface. I haven't checked, but this may have changed. In any case, best practice would be to general release tarballs using "make dist" but we currently don't do that, as far as I can tell. Also, Github isn't the only public git host around and even though it's been quite useful for us, we should be relatively flexible to move hosting whenever we need or want to. Being reliant on submodules for core dependencies makes this a little more brittle. I also agree with Christof that since portaudio development is much more active than it use to be, we should consider integrating newer stable versions as they come out. Note that I added update scripts which pull in the relevant portaudio or portmidi sources to automate this, ala: https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh <https://github.com/pure-data/pure-data/blob/master/portaudio/update.sh> Note: We have integrated some custom patches for portmidi, ie. speed limiting etc, so it's a little more problematic to replace it as a submodule right now. > On Jan 21, 2022, at 8:53 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Fri, 21 Jan 2022 18:22:48 +0100 > From: IOhannes m zm?lnig mailto:zmoel...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Why not use portaudio per default? > Message-ID: <mailto:c46ce9b3-908e-917d-0c56-a8f580c7a...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 1/21/22 14:59, Christof Ressi wrote: >> >> What about my proposition to include portaudio as a submodule > > in general i do not like git submodules. > > first of all they make problems when using 'git archive' to generate a > source tarball (e.g. when you create a 'git tag', GitHub offers you a > "Source Code" download which is created with this method). > this is often a problem for downstream packagers (e.g. for the Debian > packages) where crucial parts are missing from the source tarballs. > in the specific case of portaudio i don?t really mind, as in Debian we > are using the system-provided PortAudio (and explicitely do *not* use > the vendored version). > > 2nd, submodules do not allow for patching the vendored sources (e.g. we > *could* remove the annoying printout at Pa_Initialize() in our vendored > copy, but not with 'git submodule'). > otoh, we haven't really used this in the past, so we probably don't need > this anyhow. > > > so i really do not care. > what i do care about is that the portaudio backend implementation of Pd > remains (API-)compatible with released stable versions of PortAudio (and > ideally (API-)compatible with the version of portaudio shipped in major > linux distributions, esp. Debian) > > > >> now that it's officially on GitHub? > > this i don't really understand. what makes GitHub different from > BitBucket, GitLab, SourceForge or git.jackaudio.org > <http://git.jackaudio.org/> with respect to 'git > submodule's? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pointer cast fix
Ah yes, I remember that issue now. I will leave the warnings in place for now. > On Jan 21, 2022, at 8:42 PM, IOhannes m zmölnig wrote: > > Am 21. Jänner 2022 20:31:57 MEZ schrieb Dan Wilcox : >> >> Would it be safe to do a cast to (unsigned long)? >> >> sprintf(buf, ".x%lx", (unsigned long)x); > > no, because on LLP64 systems, an 'unsigned long' is only 32bit. > > there relevant GitHub issue is > <https://github.com/pure-data/pure-data/issues/1474> > > > mfg.sfg.jfd > IOhannes > Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] pointer cast fix
I'd like to fix a few warnings but I want to double check the cast. The warnings come from creating object hex names from pointers. sys_vgui() doesn't trigger this warning, but sprintf() does. For example: ../src/x_text.c:101:31: warning: format specifies type 'unsigned long' but the argument has type 't_textbuf *' (aka 'struct _textbuf *') [-Wformat] sprintf(buf, ".x%lx", x); Would it be safe to do a cast to (unsigned long)? sprintf(buf, ".x%lx", (unsigned long)x); Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...
> On Jan 6, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Wed, 05 Jan 2022 20:19:07 +0100 > From: Winfried Ritsch mailto:rit...@iem.at>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] Find external and install it in an custom folder > does not work anymore in Pd 052.1on Debian ... > Message-ID: <1975418.ThMadnPRZM@ras> > Content-Type: text/plain; charset="iso-8859-1" > > Thank you for the response. > > Am Mittwoch, 5. J?nner 2022, 13:07:38 CET schrieb Dan Wilcox: >>> On Jan 5, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at >>> <mailto:pd-dev-requ...@lists.iem.at> wrote: >>> >>> Message: 1 >>> Date: Tue, 04 Jan 2022 20:58:02 +0100 >>> From: Winfried Ritsch mailto:rit...@iem.at> >>> <mailto:rit...@iem.at <mailto:rit...@iem.at>>> >> >>> [1] Error response: >> That perhaps looks like a problem with deken itself. >> > It happens if Pd Document path is disabled and system path cleared. > > Not really a problem, but previous behaviour starting a file dialog did set > the > external path, so we have to change this settings before using find > externals... anyway an error shouldnt happen. Sounds like a bug yes. Please open an issue, if there isn't one already. >>> [2] Also I do not like the recent behaviour to be forced to choose default >>> folders for externals installation, since also on headless computers when >>> setup automatically, it cannot answer an file dialog on first startup, I >>> do not know who had this idea or missed the discussion, to ask for one on >>> first start of Pd and not as an option to add it later... >> > Thanks, and one correction to above, not headless but mouseless and > keyboardless, on headless it does not ask for default folder. Ok good. I would be very remiss if Pd hung on a GUI plugin when running -nogui... >> A very long discussion went on, part of which ended up as a proposal: >> >> https://github.com/pure-data/pure-data/pull/152 >> <https://github.com/pure-data/pure-data/pull/152> >> <https://github.com/pure-data/pure-data/pull/152 >> <https://github.com/pure-data/pure-data/pull/152>> >> > Thank you for the hint, now I understand... I am too late for respones ;-). > > ... anyway I thought Pd is gentleware: respectful to environments, not > wolvesware which tend to leave their marks everywhere where they can ... > but maybe it's only us old hacker generation, the younger generation got used > to it. I'm not going to rehash the whole thing but I tried to find a compromise for both, even if it's not perfect. >> There is a key in the GUI settings for the Documents path which can be set >> to "DISABLED" to avoid triggering the initial dialog. This is what is set >> when you select No. >> > ok, so I can do on remote command: > $ mkdir -p ~/.config/Pd/org.puredata.pd.pd-gui > $ echo DISABLED > .config/Pd/org.puredata.pd.pd-gui/docspath.conf I don't know the details of the Linux conf handling, but that looks correct. For macOS, this would be the equivalent: $ defaults write org.puredata.pd.pd-gui docspath "DISABLED" >> Also, the documents directory handling is implemented as a plugin, so it >> could be deleted or renamed to avoid it entirely. >> > I will take a look in this, but better dont touch the pd distributions > packages.. Maybe we need to add a plugin override in general (-noplugin "docsdir") or a docspath override specifically, ala -nodocsdir? I tried to make sure if doesn't ask if the home directory is not available or not writable (ala readonly setups), but maybe there can be another hacker-friendly check? Logic is in the plugin init proc: https://github.com/pure-data/pure-data/blob/master/tcl/pd_docsdir.tcl#L40 <https://github.com/pure-data/pure-data/blob/master/tcl/pd_docsdir.tcl#L40> My original thinking was that if you didn't want the docspath handling, you'd just press No once and never see it again, however if you are working with more than a couple normal desktop installs, this can of course not be the case. > mfg winfried >> >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika <http://twitter.com/danomatika>> >> danomatika.com <http://danomatika.com/> <http://danomatika.com/ >> <http://danomatika.com/>> >> robotcowboy.com <http://robotcowboy.com/> <http://robotcowboy.com/ >> <http://robotcowboy.com/>> > > > -- > - ao.Univ.Prof. DI Winfried Ritsch > - rit...@iem.at <mailto:rit...@iem.at> - http://iem.at/ritsch > <http://iem.at/ritsch> > - Institut fuer Elektronische Musik und Akustik > - University of Music and Dramatic Art Graz > - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...
> On Jan 5, 2022, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Tue, 04 Jan 2022 20:58:02 +0100 > From: Winfried Ritsch mailto:rit...@iem.at>> > > > [1] Error response: That perhaps looks like a problem with deken itself. > [2] Also I do not like the recent behaviour to be forced to choose default > folders for externals installation, since also on headless computers when > setup automatically, it cannot answer an file dialog on first startup, I do > not > know who had this idea or missed the discussion, to ask for one on first > start > of Pd and not as an option to add it later... A very long discussion went on, part of which ended up as a proposal: https://github.com/pure-data/pure-data/pull/152 <https://github.com/pure-data/pure-data/pull/152> There is a key in the GUI settings for the Documents path which can be set to "DISABLED" to avoid triggering the initial dialog. This is what is set when you select No. Also, the documents directory handling is implemented as a plugin, so it could be deleted or renamed to avoid it entirely. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] why no more "sys_get_audio_params" in s_stuff.h? What to do now?
I think Miller's answer is: > in the meantime objects that use s_stuff.h definitions will > probably have to track changes in the internal APIs. Which, I believe, indicates the externals need to be updated. You could make your own local version and only use it if the Pd version is >= 0.52. As to how it should be done and where is the code? I dunno. I'd suggest looking at old versions of the Pd sources to see what the old function did, then see if there is a way to replicate it in whatever manner works with Miller's updates. The functions in s_stuff.h have always been subject to change. > On Oct 23, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > By the way, the [audiosettings] externals from extended and available in > deken in the mediasettings library has the same issue and fails to create. > > what do we do now? Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] plans for next Pd release
Maybe IOhannes & Christof can give their take? Also, I believe the PR includes a compile-time define to enable/disable. > On Sep 14, 2021, at 7:37 PM, Miller Puckette wrote: > > I confess I haven't even looked at this yet. Any added thread operations in > Pd will take a lot of work for me to scrutinize (threads are the easiest way > to make software less reliable :) > > Miller > > On Tue, Sep 14, 2021 at 11:36:36AM +0100, Giulio Moro via Pd-dev wrote: >> Let me take the opportunity to flag again that it would be great if I could >> receive some feedback on this: >> >>> I have had this PR open for a while: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_pure-2Ddata_pull_1261=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=CIAxkh54128umfUyOzvHUJpNlBoM5hT8fsDZOvywKOQ=NEKBF7n4zuLkQoHhnt2oBrRg860DeQ60qejG5VrplXE= >>> . It adds threaded behaviour for disk and network I/O, making the Pd >>> audio thread "real-time safer". I went through quite a few revisions >>> courtesy of umlaeute and Spacechild1, but haven't heard from you directly. >>> I am happy to do some more work if there is interest in merging. CI build >>> currently fails because of weird "support" of ssize_t on VS (happy to hear >>> about workarounds). >> >> Thanks, >> Giulio >> >> Dan Wilcox wrote on 14/09/2021 11:18: >>> ...which reminds me I haven't had any time to look into macOS-specific >>> stuff (bad) such as usual TK issues, M1 arm builds, etc, due to too much >>> project work (good). Maybe this weekend / coming week. >>> >>>> On Sep 14, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at >>>> <mailto:pd-dev-requ...@lists.iem.at> wrote: >>>> >>>> Message: 1 >>>> Date: Mon, 13 Sep 2021 20:52:19 -0300 >>>> From: Alexandre Torres Porres mailto:por...@gmail.com>> >>>> To: Miller Puckette mailto:m...@ucsd.edu>> >>>> Cc: pd-dev mailto:pd-dev@lists.iem.at>> >>>> Subject: Re: [PD-dev] plans for next Pd release >>>> Message-ID: >>>> >>> <mailto:CAEAsFmivBpXw=kCOYO6Xjtjja8wZnKaiy3vG30cc=vhxxof...@mail.gmail.com>> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> hi, sorry to bug you Miller, but summer is ending and I was wondering about >>>> the next release if it's coming soon. >>>> >>>> cheers >>> >>> >>> Dan Wilcox >>> @danomatika >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=CIAxkh54128umfUyOzvHUJpNlBoM5hT8fsDZOvywKOQ=zjK5QkKGpT-PmrQubeExT09_VePF4PLClKFuUU7Lsmw= >>> > >>> danomatika.com >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=CIAxkh54128umfUyOzvHUJpNlBoM5hT8fsDZOvywKOQ=KZkE41QzIdpbaImsCAE9wFPhFxPOKT2p3q3zEaWbkiU= >>> > >>> robotcowboy.com >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=CIAxkh54128umfUyOzvHUJpNlBoM5hT8fsDZOvywKOQ=YHBFPwMTjJhBcivlhnTedozN_bJVvdETM-YaNsV2zOY= >>> > >>> >>> >>> >>> >>> ___ >>> Pd-dev mailing list >>> Pd-dev@lists.iem.at >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Ddev=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=CIAxkh54128umfUyOzvHUJpNlBoM5hT8fsDZOvywKOQ=VPt5_FzAma0FrHHO7yOSiWOvqe7vlOuPzDm2yRw376U= >>> >> >> >> >> ___ >> Pd-dev mailing list >> Pd-dev@lists.iem.at >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Ddev=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=CIAxkh54128umfUyOzvHUJpNlBoM5hT8fsDZOvywKOQ=VPt5_FzAma0FrHHO7yOSiWOvqe7vlOuPzDm2yRw376U= > > -- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] plans for next Pd release
...which reminds me I haven't had any time to look into macOS-specific stuff (bad) such as usual TK issues, M1 arm builds, etc, due to too much project work (good). Maybe this weekend / coming week. > On Sep 14, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Mon, 13 Sep 2021 20:52:19 -0300 > From: Alexandre Torres Porres mailto:por...@gmail.com>> > To: Miller Puckette mailto:m...@ucsd.edu>> > Cc: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] plans for next Pd release > Message-ID: ><mailto:CAEAsFmivBpXw=kCOYO6Xjtjja8wZnKaiy3vG30cc=vhxxof...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > hi, sorry to bug you Miller, but summer is ending and I was wondering about > the next release if it's coming soon. > > cheers Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] -verbose vs logpost() (IOhannes m zmoelnig)
Maybe an additional -loglevel which allows you set the level explicitly? -verbose to me would set the log level to verbose overall & -noverbose would set it back to the default. Also tangentially, I would also bring up the handling of some of these flags which affect the state: using -verbose also sets the verbose setting which is then saved wirh the user settings. I find this annoying as I would rather have the command line flags like this be *temporary* and not affect the actual setting itself. To me changing the value directly in the GUI should (as it does now). I believe I opened an issue about this already. > On Aug 26, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > with the latter in mind, we might even use multiple "-noverbose" flags > to lower the verbosity (at least of the stderr) below post() - so that > only errors would be visible. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ot] asiosdk2.3 gone from steinberg's website
That should be it. It looks like they moved their downloads to a subdomain and the new direct URL is on download.steinberg.net <http://download.steinberg.net/> so I you are scripting and want the 2.3 version specifically: https://download.steinberg.net/sdk_downloads/asiosdk2.3.zip <https://download.steinberg.net/sdk_downloads/asiosdk2.3.zip> Maybe add this info to the asio/README.txt: https://github.com/pure-data/pure-data/tree/master/asio <https://github.com/pure-data/pure-data/tree/master/asio> ie. "You can download a specific version using https://download.steinberg.net/sdk_downloads/asiosdk#.#.zip; etc > On Aug 25, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Date: Wed, 25 Aug 2021 10:42:06 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: "pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>" <mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] [ot] asiosdk2.3 gone from steinberg's website > Message-ID: <mailto:c98d37d7-fb61-659c-2525-ef74b6372...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > i just found out on the CI that since yesterday, steinberg obviously > have removed the old asiosdk download? from their website. > > apparently a newer version can be obtained from > https://www.steinberg.net/asiosdk <https://www.steinberg.net/asiosdk> > > mgdasr > IOhannes > > ? http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip > <http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip> Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] unifying loglevels
Sounds good to me. I agree that 0 (CRITICAL) as the baseline and the levels as an unsigned int is better. With the enum, understanding the numeric values should not be an issue moving forward. I would suggest considering a compatibility mode / compile time option to preserve existing functionality for those that *really* need it, then it can be removed later on (hopefully). I can imagine someone quickly trying to run a project with old pre-compiled externals and getting flooded with prints which they could at the least disable via some compatibility flag, however the amount of time it might take for them to figure this out could make the point moot. OTOH if adding this ends up taking too much time/focus for little benefit, by all means don't do it. :) > On Aug 25, 2021, at 10:35 AM, pd-dev-requ...@lists.iem.at wrote: > > Date: Tue, 24 Aug 2021 15:59:34 +0200 > From: IOhannes m zmoelnig mailto:zmoel...@iem.at>> > To: Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at> > Subject: [PD-dev] unifying loglevels > Message-ID: <02113e2f-d09f-6cb4-bc88-c25201fc9...@iem.at > <mailto:02113e2f-d09f-6cb4-bc88-c25201fc9...@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > TL;DR i'd like to propose to unify the loglevels as used by verbose() > and logpost() Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd breaks zexy (?)
My understanding has always been: m_pd.h is public and generally shouldn't change without some sort of compatibility coverage. Anything other .h is private. I wrote d_soundfile.h and s_net.h as private headers, but they could be included in m_pd.h to make them public for example. We could add commenting marking them as such. > On Aug 21, 2021, at 5:03 AM, pd-dev-requ...@lists.iem.at wrote: > >> Well, I've never been able to articulate a clear and complete policy... >> Roughly speaking, I'm maintaining source and binary compatibility for >> anything >> that uses the public API (m_pd.h) and trying not to break things that use >> private APIs (g_vanas.h, s_stuff.h and, privater still, m_imp.h"). Meanwhile >> there's a profusion of ".h" files I didn't write (d_soundfile.h, >> g_all_guis.h, >> etc) that I've never formed a policy for. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] plans for next Pd release
Personally, as this affects fundamental objects, I would do both. As this can be a workflow issue, my thinking is: * Assume vast majority of users & use cases want fixed behavior (or don't particularly care), so update objects to use new/fixed behavior by default. * Add a compatibility flag for older projects which *rely* on older behavior for *all* instances of the objects. * Add a creation argument to the objects for those cases where people rely on the old behavior for certain situations, but also want the newer behavior for most other instances. * Document the old versus new behavior in a help-patch subpath with comparisons. > On Aug 5, 2021, at 10:55 AM, pd-dev-requ...@lists.iem.at wrote: > > Date: Thu, 5 Aug 2021 10:55:38 +0200 > From: Max mailto:abonneme...@revolwear.com>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] plans for next Pd release > Message-ID: <265a5773-2750-af8b-22a5-d01bdc4f6...@revolwear.com > <mailto:265a5773-2750-af8b-22a5-d01bdc4f6...@revolwear.com>> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 05.08.21 03:56, Miller Puckette via Pd-dev wrote: >> I'm using that as rarely as I can, so far only for bug fixes. I don't think >> a limit on numerical accuracy is exactly a bug. I think it's nicer to most >> users not to have them have to bother with specifying a compatibility >> version. > > Maybe make the numerical accuracy a settable variable with the current > depth as a default? (bonus: instant bitcrusher effect) Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] plans for next Pd release
Howdy Miller, Let me know what areas I can help with. I saw a comment about having problems compiling d_soundfile_caf.c on windows? Also, there are a couple of things on macOS which should be updated, including checking if the latest Tcl/Tk Wish can be built natively for arm64. I last looked around February and it wouldn't build. > On Jul 13, 2021, at 8:57 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 1 > Date: Tue, 13 Jul 2021 10:22:17 -0700 > From: Miller Puckette mailto:m...@ucsd.edu>> > To: pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] plans for next Pd release > Message-ID: <20210713172217.v4ch3b3dk7go7...@ucsd.edu > <mailto:20210713172217.v4ch3b3dk7go7...@ucsd.edu>> > Content-Type: text/plain; charset=us-ascii > > (re-send - I had sent to pd-...@iem.at <mailto:pd-...@iem.at> but that now > seems to be defunct...) Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] Ability to access error messages from patch
Some quick thoughts on my end. # error outlets Let's say if we were to consider adding some sort of "standard outlet" for errors, how many objects are we talking about? I assume not every object but perhaps those which read/write files and the net objects? That's not so many, really. I already added a general "info" outlet for [soundfiler] which could easily be extended by outputting an error list ala "error # msg symbols..." or simply "errno." One negative is that this sort of approach becomes relatively arbitrary and supported by only a few objects, some which may have a dedicated error outlet and others which may have a generalized outlet with some sort of error list selector etc. OTOH the growth of Pd's objects over time has ensured this kind of "arbitrariness" is part and parcel, so maybe it is less so. A positive point is that it's relatively easy to communicate and work with. For instance, we have this paradigm to a small degree where [netrecieve] will output a 0 if the connect message failed. # errno object As Pd is more or less structured after C to some degree, I like the idea of formalizing something like errno and simply using the standard defined error numbers. At least there is something already to use, however the standard values are probably not enough to cover all cases but at least "can't open file" or "unsupported parameter" etc are there. This would force a certain design paradigm where you need to do A then check error, then maybe do B and check error, etc. Sure, that's how you do it in C, for most things, but it's also a lot of boilerplate and boilerplate is much more annoying in a patcher. # (sub)patch errors I find a sub(patch) level error object enticing, ie. anything in this (sub)patch will throw an error to this object. I think IOhannes called them exceptions, but I would avoid that naming as I assume it will not halt or crash Pd if the error is not handled. Like errno, this would force a certain design paradigm where you need to group object + error object all the time. In some cases it wouldn't bother me and in others I'd find it annoying. It would be simple to communicate however and relatively easy to integrate into Pd by, I assume, a new API call where objects can raise a "patch level" error as opposed to global stdout/stderr all console. > On Jun 14, 2021, at 11:25 PM, pd-dev-requ...@lists.iem.at wrote: > > Method calls which can generate an error send the error code to a global > [errno] object and the user can query the current error state with a > bang. This would be similar to 'errno' in C. > > If the user queries the errno immediately after the method call, Pd's > determinism guarantees that the error really belongs to that method > call. We would have to reserve a special value (e.g. "0") to mean "no > error". > > My main point is that errors should not be *sent* by global or > canvas-local objects, but that they should be *queried*. This way the > user doesn't have to deal with cross talk between different objects. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] dlopen error _class_addlist
In the end, I didn't have the time to find a deep fix and instead resorted to compiling the external sources into the application. Thankfully, everything is working and I can make the release. When I revisit building Pd for native Apple arm64, I imagine this issue will need to be fixed for general dynamic external usage. > On Jun 10, 2021, at 1:48 AM, Dan Wilcox wrote: > > More likely that my additions to pd-lib-builder form arm64 are incomplete. > I’m just sure where to start debugging. > > enohp ym morf tnes > --- > Dan Wilcox > danomatika.com > robotcowboy.com > > >> On Jun 10, 2021, at 12:11 AM, Miller Puckette wrote: >> >> Hmm... I think if there are 100s of undefined symbols the extern loader >> in Pd only reports one of them (seemingly choosing one at random). So this >> is probably a failure of dlopen to see any symbols from the calling pd at >> all. >> >> But why this should happen for arm and not for intel arch escapes me... >> perhaps Mac has added some more hurdles to dynamically loading code, but >> only turned them on for arm? >> >> M >> >>> On Wed, Jun 09, 2021 at 11:57:47PM +0200, Dan Wilcox wrote: >>> Howdy all, >>> >>> I'm building an application which uses libpd and a couple pre-compiled >>> externals as universal macOS app for x86_64 and arm64 (new Apple CPU). So >>> far, building and signing etc is working but now I'm running into an issue >>> when the externals are being loaded on arm64: >>> >>> Pd: error:../pd/zirkhoa.d_fat: dlopen(.../pd/zirkhoa.d_fat, 10): Symbol not >>> found: _class_addlist >>> Referenced from:.../pd/zirkhoa.d_fat >>> Expected in: flat namespace >>> in .../pd/zirkhoa.d_fat >>> >>> None of the external sources use class_addlist, so I assume that's >>> something internal? Could this be an issue with the new architecture within >>> libpd / the pd core? >>> >>> The x86_64 builds run fine on Intel machines. >>> >>> >>> Dan Wilcox >>> @danomatika >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=LvNXgYHyFcUCyShMQ0mI_Ll4R4pH0Kgn8yAJkEgekOg= >>> > >>> danomatika.com >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com_=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=SKBh_sypC3yNes38ScMl41aB_Z3esQJ-E7BS6Djq9CQ= >>> > >>> robotcowboy.com >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com_=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=Fqk66GY9Z4SMR9e-lkW8PowtnWg_LgRFEfy-FOBWXCU= >>> > >>> >>> >>> >> >>> ___ >>> Pd-dev mailing list >>> Pd-dev@lists.iem.at >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Ddev=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=BwbmzaM2LCbKPnuuD2nvhbl_nvQAd9F1jwopG6evKpY= >>> >> >> >> -- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] dlopen error _class_addlist
More likely that my additions to pd-lib-builder form arm64 are incomplete. I’m just sure where to start debugging. enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com > On Jun 10, 2021, at 12:11 AM, Miller Puckette wrote: > > Hmm... I think if there are 100s of undefined symbols the extern loader > in Pd only reports one of them (seemingly choosing one at random). So this > is probably a failure of dlopen to see any symbols from the calling pd at > all. > > But why this should happen for arm and not for intel arch escapes me... > perhaps Mac has added some more hurdles to dynamically loading code, but > only turned them on for arm? > > M > >> On Wed, Jun 09, 2021 at 11:57:47PM +0200, Dan Wilcox wrote: >> Howdy all, >> >> I'm building an application which uses libpd and a couple pre-compiled >> externals as universal macOS app for x86_64 and arm64 (new Apple CPU). So >> far, building and signing etc is working but now I'm running into an issue >> when the externals are being loaded on arm64: >> >> Pd: error:../pd/zirkhoa.d_fat: dlopen(.../pd/zirkhoa.d_fat, 10): Symbol not >> found: _class_addlist >> Referenced from:.../pd/zirkhoa.d_fat >> Expected in: flat namespace >> in .../pd/zirkhoa.d_fat >> >> None of the external sources use class_addlist, so I assume that's something >> internal? Could this be an issue with the new architecture within libpd / >> the pd core? >> >> The x86_64 builds run fine on Intel machines. >> >> >> Dan Wilcox >> @danomatika >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=LvNXgYHyFcUCyShMQ0mI_Ll4R4pH0Kgn8yAJkEgekOg= >> > >> danomatika.com >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com_=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=SKBh_sypC3yNes38ScMl41aB_Z3esQJ-E7BS6Djq9CQ= >> > >> robotcowboy.com >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com_=DwIFAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=Fqk66GY9Z4SMR9e-lkW8PowtnWg_LgRFEfy-FOBWXCU= >> > >> >> >> > >> ___ >> Pd-dev mailing list >> Pd-dev@lists.iem.at >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Ddev=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=u49QYs0av5sCAWq6vJXjNrgCURqVPfBMRfDJ4M2Rc8k=BwbmzaM2LCbKPnuuD2nvhbl_nvQAd9F1jwopG6evKpY= >> > > > -- ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[PD-dev] dlopen error _class_addlist
Howdy all, I'm building an application which uses libpd and a couple pre-compiled externals as universal macOS app for x86_64 and arm64 (new Apple CPU). So far, building and signing etc is working but now I'm running into an issue when the externals are being loaded on arm64: Pd: error:../pd/zirkhoa.d_fat: dlopen(.../pd/zirkhoa.d_fat, 10): Symbol not found: _class_addlist Referenced from:.../pd/zirkhoa.d_fat Expected in: flat namespace in .../pd/zirkhoa.d_fat None of the external sources use class_addlist, so I assume that's something internal? Could this be an issue with the new architecture within libpd / the pd core? The x86_64 builds run fine on Intel machines. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Polling: Execute a function every X ms from within the external.
Maybe this is a good example to add somewhere? > On Apr 30, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote: > > Message: 2 > Date: Thu, 29 Apr 2021 23:12:12 +0200 > From: Christof Ressi mailto:i...@christofressi.com>> > To: pd-dev mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] Polling: Execute a function every X ms from > within the external. > Message-ID: <mailto:eb2b0430-8d03-96ed-45de-2555e9321...@christofressi.com>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Here's how: Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Problem with the error function
Well, "expert" or not, nobody can remember all the details and we can
potentially save someone pain later.
> On Feb 22, 2021, at 6:03 PM, Pierre Guillot wrote:
>
> IMO, it could be useful! ...but perhaps I didn't find this solution earlier
> because I'm not an expert on the linking mechanism and it would have been
> obvious for somebody with strong basics knowledge about it.
>
> Le lun. 22 févr. 2021 à 15:45, Dan Wilcox <mailto:danomat...@gmail.com>> a écrit :
> Do you think it would be useful to add this to the libpd README or a wiki
> page?
>
>> On Feb 22, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at
>> <mailto:pd-dev-requ...@lists.iem.at> wrote:
>>
>> Message: 1
>> Date: Sun, 21 Feb 2021 17:51:39 +0100
>> From: Pierre Guillot > <mailto:guillotpier...@gmail.com>>
>> To: pd-dev mailto:pd-...@iem.at>>
>> Subject: Re: [PD-dev] Problem with the error function
>> Message-ID:
>> > <mailto:CALPKkhofbAgTPjohGMyvNFt3bau4yh=a+snv9_g3pxp3o+r...@mail.gmail.com>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Finally, I think I found the solution. I simply have to use
>> "-Wl,-Bsymbolic" option for the linker (not only for Pd/libpd but also for
>> the VST/LV2 libraries).
>>
>> set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-Bsymbolic")
>> set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -Wl,-Bsymbolic")
>>
>> Hope this helps someone else :)
>
>
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
>
>
>
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Problem with the error function
Do you think it would be useful to add this to the libpd README or a wiki page?
> On Feb 22, 2021, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:
>
> Message: 1
> Date: Sun, 21 Feb 2021 17:51:39 +0100
> From: Pierre Guillot <mailto:guillotpier...@gmail.com>>
> To: pd-dev mailto:pd-...@iem.at>>
> Subject: Re: [PD-dev] Problem with the error function
> Message-ID:
><mailto:CALPKkhofbAgTPjohGMyvNFt3bau4yh=a+snv9_g3pxp3o+r...@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> Finally, I think I found the solution. I simply have to use
> "-Wl,-Bsymbolic" option for the linker (not only for Pd/libpd but also for
> the VST/LV2 libraries).
>
> set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-Bsymbolic")
> set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -Wl,-Bsymbolic")
>
> Hope this helps someone else :)
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
[PD-dev] Using Pd on macOS with Tcl/Tk installed via Homebrew
Howdy all, Just a quick note that I tested running Pd from the command line using a newer version of Tcl/Tk installed via the Homebrew package manager. Works fine, Tk Wish 8.6.11 on macOS 11.2. You mainly need to make sure the right wish app is invoked and *not* the old buggy version which comes with the system. For testing, I used: /opt/homebrew/opt/tcl-tk/bin/wish8.6 ~/src/pure-data/tcl/pd-gui.tcl If you add /opt/homebrew/opt/tcl-tk/bin to the start of your PATH, then Pd would use the alternate install automatically. Anyway, one more step towards being able to build & install Pd to the system via Homebrew. ---- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD 0.51-4 bug fix candidates
Also, perhaps it will make sense to integrate building Wish.app as part of the build process for Pd 0.52. So far, "make app" (re)uses the Wish.app in the mac/stuff tarball, but this will get untenable if Tk is now sensitive to the originating build system. This could be changed via adding a couple make targets which call tcltk-wish.sh to download & build and we can set the Tk version number in the Makefile and/or configure. In any case, I will revisit the build system to add Mac arm support for 0.52 once 0.51-4 is out. > On Dec 20, 2020, at 9:56 AM, Dan Wilcox wrote: > > It was only a matter of time and we will need to do this going forward to > support Mac arm64 anyway. > > In the tests of my builds, someone responded in 10.9, so it works at least > that far back. This fits up with my work experience where the more recent > line is around 10.9 or 10.10 due to API changes and deprecations in the OS. > > One option is to make the 32 but builds for 10.6 - 10.8 and have the 64 bit > build for newer system only. > > For Mac arm64 + x86_64 builds (universal2), we need at least a 10.15 system I > believe or possibly 11.0 in order to run a new enough Xcode which will > support arm64. Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD 0.51-4 bug fix candidates
It was only a matter of time and we will need to do this going forward to support Mac arm64 anyway. In the tests of my builds, someone responded in 10.9, so it works at least that far back. This fits up with my work experience where the more recent line is around 10.9 or 10.10 due to API changes and deprecations in the OS. One option is to make the 32 but builds for 10.6 - 10.8 and have the 64 bit build for newer system only. For Mac arm64 + x86_64 builds (universal2), we need at least a 10.15 system I believe or possibly 11.0 in order to run a new enough Xcode which will support arm64. enohp ym morf tnes --- Dan Wilcox danomatika.com robotcowboy.com > On Dec 20, 2020, at 5:52 AM, Miller Puckette wrote: > > OK... as I feared - sure enough, when I build Wish 8.6.10 on an OS 10.14 > machine, I get good scrollbar behavior on 10.14 - but that build of Wish > won't run on OS 10.7. > > Meanwhile, building the exact same Wish (with all Dan's patches) on my > 10.7 machine makes a working Pd on 10.7 (not ideal because the scrollbars > don't darken when I hover the ouse over them, but visible and working)... > but, as I checked over VNC on the 10.14 machine, scrollbars are invisible. > > At this point the only thing I can think of to do is to release Pd in "new OS" > and "old OS" versions (in addition to the 32-bit older-yet-OSes version). > I'll have to rely on people with OSes between 10.7 and 10.14 to find out how > far back one can run a 10.14-built version (I should put this info on the > download site). > > This is ugly, but I can't see spending the time to chase this down any further > (especially on Dan's part - he's already put in a heroic effort). > > So unless someone has a better idea I'll just release my 10.14 build (also as > a "test 3") and plan to release 0.51-4 in, ugh, 3 Mac builds. > > Miller > >> On Sat, Dec 19, 2020 at 05:15:00PM -0800, Miller Puckette via Pd-dev wrote: >> Nope, false alarm, the difference is apparently from signing the app. >> Still digging... >> M >>> On Sat, Dec 19, 2020 at 05:08:41PM -0800, Miller Puckette via Pd-dev wrote: >>> Ha, it looks like Pd-0.51-4test3.app/Contents/MacOS/Pd is a different file >>> from >>> the version of Wish I compiled... my build script must be turned around >>> somehow. >>> >>> M >>> >>> On Sun, Dec 20, 2020 at 02:03:42AM +0100, Dan Wilcox wrote: >>>> When you run tcltk-wish.sh, it should say if each patch was applied in the >>>> output at the beginning. >>>> >>>>> On Dec 20, 2020, at 2:02 AM, Miller Puckette wrote: >>>>> >>>>> yeah, did that... >>>>> >>>>> OTOH I'm compiling on a 10.7 machine. Perhaps there's something in the >>>>> compile chain that changed. >>>>> >>>>> OR, maybe I'm doing something wrong... I'll have another look and try to >>>>> make sure the patches made it in. >>>>> >>>>> M >>>>> >>>>> On Sun, Dec 20, 2020 at 01:39:10AM +0100, Dan Wilcox wrote: >>>>>> Sorry, forgot the steps. Assuming Pd is already build via make, they >>>>>> should be: >>>>>> >>>>>> mac/tcltk-wish.sh 8.6.10 >>>>>> mac/osx-app.sh -w Wish-8.6.10.app 0.51-4test3 >>>> >>>> >>>> Dan Wilcox >>>> @danomatika >>>> <https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!UW3LPTQFEzzh9f9DeHZT3taRongQhErAjVX4MKBFstYlOyztJr0AWl2Opeh0$ >>>> > >>>> danomatika.com >>>> <https://urldefense.com/v3/__http://danomatika.com/__;!!Mih3wA!UW3LPTQFEzzh9f9DeHZT3taRongQhErAjVX4MKBFstYlOyztJr0AWlfKcYVX$ >>>> > >>>> robotcowboy.com >>>> <https://urldefense.com/v3/__http://robotcowboy.com/__;!!Mih3wA!UW3LPTQFEzzh9f9DeHZT3taRongQhErAjVX4MKBFstYlOyztJr0AWneLgTKU$ >>>> > >>>> >>>> >>>> >>> >>> >>> >>> ___ >>> Pd-dev mailing list >>> Pd-dev@lists.iem.at >>> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!SCxwfJnWP3T-n-XMzb9CK8JnFyM5U7DyCbmiBxJNy5aRPuJgkDRvnrr_o2gn$ >>> >> >> >> >> ___ >> Pd-dev mailing list >> Pd-dev@lists.iem.at >> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!UaULM2_OII07cv8qUigM42lvCBm9au3SRP0sLCZDkOptomtNJRb7AGq7nw2T$ >> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
