Re: [PD] Help with OSX App minefield
On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote:
On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely. It
will only ever be 32-bit, and starting in 10.7, everything is 64-bit.
Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link
to the Carbon system libraries. Both run.
Considering that Apple has dropped support even for some older 64-bit Macs, I
think using Carbon is surely a dead end.
http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-bit-macs-gently-into-that-good-night/
What is the relevance of what you've written and linked to?
When I have time to look at what's required to get tkpath to use
the updated tkMac headers found in newer versions of tcl/tk, I'll do it.
Meanwhile people will have a working version of Pd-l2ork on OSX
to play with.
-Jonathan
.hc
An update to the Pd-l2ork port:
* figured out how to build tkpath against the Carbon stuff. It runs fine now.
* got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
* currently working on an issue with the Shift key sticking-- that is, if I
do Shift-RightArrow to move an object by 10 pixels, when I release
Shift and then do RightArrow it continues moving the object by
10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best,
Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on
OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
* I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the
system ones. (Tried both Xcode and command line tools). Anybody
have hints for that?
* I can't figure out how to build the externals in extra. If I do
make the linker doesn't find any of the m_pd.h functions, even if
I do the ugly hack of copying m_pd.h to the directory.
* I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to
the usual places on the system). Is there a trick to this?
* key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may
remedy this, but I'm not sure yet.
Best,
Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello,
I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do:
Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
* Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa.
So I
must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be
ok because Pd-extended.app is currently set up to use Carbon.
* Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the
gui-rewrite
What I've done so far:
* updated the configure file successfully
* made a workaround for statbuf from stat.h not existing on OSX (in s_main.c)
* made a workaround for RTLD not existing after ./configure and trying to
make (s_loader.c)
* successfully compiled Pd-l2ork
* checked that tkpath actually works on OSX. It seems to work, using tcl/tk
w/Carbon
instead of Cocoa.
* used otool and install_name_tool to change libPdTcl.dylib libraries to
point at the
App's Framework directory instead of system directories
* changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does
successfully)
What crashes so far:
* inside pd.tk, I'm trying to do this:
load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report
referencing the first line
of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp)
{
const char *argv = Tcl_GetVar(interp, argv, 0);
***
Any ideas where to begin to debug this? Is there some code I can add to
Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here:
http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
Re: [PD] Building externals on OSX
On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. -Jonathan On Oct 21, 2013, at 9:12 PM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: *From:*Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com *Subject:**Re: [PD] Building externals on OSX* *Date:*October 21, 2013 4:20:55 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at On 10/21/2013 02:09 PM, Hans-Christoph Steiner wrote: That sounds like you're building pd/extra from Pd-vanilla. I never had any luck with that build system. That's part of the reason why I ripped out extra from Pd-extended and made it a standalone library. It was much easier to make it work that way. Figured this one out, too. It was a problem of building 64 bit binaries-- I just ended up building for i386 and the problem went away. If I'm going to go to the trouble of building for both architectures, then I might as well go ahead and build ppc, too. So the real solution would be for me to remove my current xcode setup and read all the stackoverflow workarounds telling which older XCode version to setup an environment that supports building for ppc. -Jonathan Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 2013-10-22 13:14, Jonathan Wilkes wrote: On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. I think Apple hardware has a MTBF of about 3 years; their business model relies on customers junking the old model at ever increasing rates and buying the new one. The old one after all never quite worked properly because they sold it before it was ready. I have a bunch of old Macs around here that mostly won't start up anymore. Usually the hard drive or the power supply fails. Good luck replacing either. I'm pissed because I've lost a lot of my work that way and with the constant incompatibility from one version of MacOS to the next not to mention the uninteroperability with any other OS. So anyway PPC is obsolete and such a machine trying to run a new version of any software would probably choke on it anyway. And OSX on PPC was really slow, system9 worked better. I think the best thing is to not upgrade at all and try to keep it running the old software while not stressing the hardware in any way. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On Oct 22, 2013, at 1:07 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] Building externals on OSX Date: October 22, 2013 1:14:41 PM EDT To: pd-list@iem.at On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Yes. It's a different instruction set and Rosetta, the PCC compatibility layer, won't run an OSX 10.7+. Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Your political bias notwithstanding (I say use what works for you), I have a 4 year old Apple laptop that still does everything I need with the latest version of OSX and I plan to upgrade to OSX Mavericks when it comes out. That's pretty good, as I had a job when I bought it and I am currently an unemployed artist working on his thesis right now, so it's good this sleek and sexy device is not yet an ugly, unprofitable one. As with anything, not everyone buys the newest one every iteration and I can say, without any hardware issues whatsoever so far, I got what I paid for. In any case, I've long thought of helping with the OSX compatibility for Pd (updating GEM to Cocoa/64 bit for instance) but I honestly don't have the time or support right now. Maybe next spring I can do a reverse kickstarter? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
The best approach might be to just support all proprietary OSes by compiling Pd to emscripten and building an interface using one of the various html5canvas/svg javascript libraries. Then, when the EME DRM hooks get forced into html5, use them to require a pay-walled subscription infrastructure on anyone not using a free software operating system. One could essentially do it by packaging some DRM blobs for Debian non-free and various other distros (Ubuntu PPAs, etc.). Then, like Apple, every time Pd gets updated, change the API for the blob. Free software OS users would automatically get it with their system update (or by downloading the newest Pd binary)-- when they want to run Pd through the browser the EME infrastructure sends the blob a puzzle and the blob sends back the answer that lets users run Pd-on-the-web without any limits or pay-wall. (Either once per session or sending it periodically.) Of course you'd get some perturbed Mac devs who could just try to remove the DRM hooks, but that's the reason to get a few extremely broad patents on some of the fundamental aspects of the way the message dispatcher speaks to the gui (or something else similarly trivial) and just threaten anyone who tries to remove the arbitrary restrictions with lawsuits. Besides, you'd only charge an _extremely_ modest fee per month in order to real-time DSP in the cloud on proprietary OS. After all it costs money to develop software, and if those users want unrestricted access and lower latency they can install a free software OS and get it for _free_. I wouldn't want to go through the trouble of doing this, but it's a fun thought experiment to twist idiotic technologies and counterproductive business models in the interest of freedom and sharing. Best, Jonathan - Original Message - From: Martin Peach martin.pe...@sympatico.ca To: Jonathan Wilkes jancs...@yahoo.com; pd-list@iem.at Cc: Sent: Tuesday, October 22, 2013 1:53 PM Subject: Re: [PD] Building externals on OSX On 2013-10-22 13:14, Jonathan Wilkes wrote: On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. I think Apple hardware has a MTBF of about 3 years; their business model relies on customers junking the old model at ever increasing rates and buying the new one. The old one after all never quite worked properly because they sold it before it was ready. I have a bunch of old Macs around here that mostly won't start up anymore. Usually the hard drive or the power supply fails. Good luck replacing either. I'm pissed because I've lost a lot of my work that way and with the constant incompatibility from one version of MacOS to the next not to mention the uninteroperability with any other OS. So anyway PPC is obsolete and such a machine trying to run a new version of any software would probably choke on it anyway. And OSX on PPC was really slow, system9 worked better. I think the best thing is to not upgrade at all and try to keep it running the old software while not stressing the hardware in any way. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 10/22/2013 02:52 PM, Dan Wilcox wrote: On Oct 22, 2013, at 1:07 PM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: *From:*Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com *Subject:**Re: [PD] Building externals on OSX* *Date:*October 22, 2013 1:14:41 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at On 10/21/2013 09:38 PM, Dan Wilcox wrote: Errr. That's not so easy. You need the 10.5 SDK which you can only get with a *really* old version of Xcode which you probably can't install on anything newer than OSX 10.6. It's possible to put older SDK's themselves into the right place but, for something as old as the 10.5 SDK, it may not even work anymore. The only reliabel way to use an old machine with 10.5 or 10.6 and an old version of Xcode, probably Xcode 3.something. IMHO, at this point, it's best to drop support for PPC for new versions of pd. The *vast vast vast* majority of OSX users have moved on at this point. Just to make sure I understand: if someone has an old PPC Mac, they cannot run stuff compiled for i386 or x86_64. There is no compatibility-mode or anything they can use to run the software. Is this correct? Yes. It's a different instruction set and Rosetta, the PCC compatibility layer, won't run an OSX 10.7+. Well, if it's an enormous amount of trouble to continue supporting it then I can see dropping it. Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% Thanks. Those are low numbers, but I'd imagine the number of PPC users is still fairly high: http://www.statisticbrain.com/apple-computer-company-statistics/ I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) Your political bias notwithstanding (I say use what works for you), Well, I'd call it a political stance. And where it seemed quirky and deeply personal when I first adopted it, it now seems simply to be a restatement of the scientific method for computer security, at a time when there have been revelations that show our computers really need to be as secure as possible against attacks. I'd also point out that yours is a political stance. While I understand it, I must disagree with it because in terms of security it is much more difficult to use the scientific method to check whether the specs actually fit the implementation. In some cases on proprietary OSes neither are known so you're forced to reverse engineer the software, and for complex systems that's too time consuming and expensive to do. I have a 4 year old Apple laptop that still does everything I need with the latest version of OSX and I plan to upgrade to OSX Mavericks when it comes out. That's pretty good, as I had a job when I bought it and I am currently an unemployed artist working on his thesis right now, so it's good this sleek and sexy device is not yet an ugly, unprofitable one. As with anything, not everyone buys the newest one every iteration and I can say, without any hardware issues whatsoever so far, I got what I paid for. In any case, I've long thought of helping with the OSX compatibility for Pd (updating GEM to Cocoa/64 bit for instance) but I honestly don't have the time or support right now. Maybe next spring I can do a reverse kickstarter? It's probably a much better idea to just do a Kickstarter. :) Best, Jonathan Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
I'm not going to argue OS politics, again use what works best for you. I can understand the frustration with how the build system works on OSX. It is actually really nice in a lot of ways but it took me a while to get the hang of it after switching from Linux. Without counting Debian, I still think there's really no need at this point to support a PPC build for OSX. When I wrote drop PPC support in earlier emails, I was referring only to OSX. The code as it is now should compile just fine on Debian PPC since the only architecture differences as far as I know would be compiling for little endian versus big endian on Intel. I don't think there are any architecture specific assembly / function calls in Pd. So in the end, dropping OSX PPC support helps in simplifying the build scripts at least. Again, I think there's really no need to host newer Pd OSX PPC binaries, just leave the last one there since anyone using it will be on a much older version of OSX anyway. On Oct 22, 2013, at 5:05 PM, pd-list-requ...@iem.at wrote: Also, do you have any references for the claim that the vast majority of OSX users have moved away from PPC? http://update.omnigroup.com/ (Hardware / CPU type): Intel 97.8% PPC 2.2% https://www.adium.im/sparkle/ (CPU type): Intel 97.83% PPC 2.71% Thanks. Those are low numbers, but I'd imagine the number of PPC users is still fairly high: http://www.statisticbrain.com/apple-computer-company-statistics/ I find Jobs' claim that Apple doesn't ship junk to generally be true, and combined with their development model the unfortunate result would seem to be that poor people still using their once sleek and sexy devices are ignored along with their now ugly, unprofitable devices. Well, those sleek and sexy PPC devices were last made sold in 2005, so it's not a surprise the vast majority of people using OSX have Intel machines mainly because software developers ( the OS) have moved on to 32 bit and now 64 bit intel years ago. Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) Your political bias notwithstanding (I say use what works for you), Well, I'd call it a political stance. And where it seemed quirky and deeply personal when I first adopted it, it now seems simply to be a restatement of the scientific method for computer security, at a time when there have been revelations that show our computers really need to be as secure as possible against attacks. I'd also point out that yours is a political stance. While I understand it, I must disagree with it because in terms of security it is much more difficult to use the scientific method to check whether the specs actually fit the implementation. In some cases on proprietary OSes neither are known so you're forced to reverse engineer the software, and for complex systems that's too time consuming and expensive to do. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Packages for Ubuntu 13.10?
Hi, Will the Pd-extended repositories be updated for Ubuntu 13.10 at any point? Currently there's no way to install it other than compiling from source Kind regards, Antonio -- anto...@hellocatfood.com http://www.hellocatfood.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Packages for Ubuntu 13.10?
You can still install it from the repo. Just use the raring distro instead of saucy. On 10/22/2013 06:47 PM, Antonio Roberts wrote: Hi, Will the Pd-extended repositories be updated for Ubuntu 13.10 at any point? Currently there's no way to install it other than compiling from source Kind regards, Antonio ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building externals on OSX
On 23/10/13 05:12, Jonathan Wilkes wrote: Debian supports PPC, no? Anyone know how it does on the old machines? I suppose since Pd is in the repos one could say it still supports PPC. :) I don't think their main ppc target is Apples now, and the Open Firmware boot system is very old, I think you need to go back a few versions to get a debian installer that still does that, then maybe you can upgrade from there, but I imagine newer ppc stuff won't be using altivec, and without altivec and the quicktime stuff optimised for it they are not so useful, really it is probably much more sensible to run OSX 10.4.9 on them and a pd that runs on that. I have an old ppc mac-mini still running from the days I used OSX, it is running an old debian. I never bought any intel macs, but certainly it took years before the intel mac-minis caught up to the speed of the G4 ones in terms of editing and playing video. Back in early Final Cut Pro days the ppc apples could run video editing much better than anything else even close to the price, but that is ancient history now and Apple mostly sells hand-held gadgets now. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
