Re: [PD] Help with OSX App minefield
> But the Pd dev community has always been not so good at coordinated efforts. > There is a history of lots of effort going into semi-compatible dev forks which > mostly die out after a run (pd-devel, desiredata, vibrez, etc. etc.) Perhaps Pd- > extended or pd-l2ork will be the next one to die out... > > .hc Hans, Your heart is in the right place but we also need to practice what we preach. I think the FOSS community's greatest weakness is also its greatest strength--if things die away and even get duplicated, they have done so for a specific reason. I find the existence of pd-l2ork essential in what I do as I am sure you and many others find pd-extended and/or pd-vanilla. Just like Miller, you, I, and many other core contributors to the Pd ecosystem, I am flattered that others may find my flavor useful but I have no intentions of trying to make anyone a convert. In other words, having options is a good thing and we all ultimately choose to use whatever best addresses our needs, even if that means introducing a level of redundancy. Our projects have also inspired each other on various occasions and I see this as a good thing--at the very least I see this as a great source for motivation. I have no intentions of dropping pd-l2ork anytime soon because it has proven particularly useful in my own work. And even if one day I do stop developing it, I have no expectations about its future. Ideally, someone else will pick up the code and run with it. And if no one does I guess that will be the testament to how bad this branch was and maybe it will be a good thing that it will wither and die away. OTOH, it may persist and transform into something none of us could ever even imagine, and that is fine as well. Ultimately, pd-l2ork serves my purpose (just like I anticipate pd-extended serves yours) and is IMO different enough in its agenda/focus to warrant its existence--and as long as that continues to be the case I am fairly confident that we'll all continue plugging away at that next iteration of our preferred platform. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
On Nov 4, 2013, at 1:42 PM, Jonathan Wilkes wrote: > On 11/04/2013 09:51 AM, Hans-Christoph Steiner wrote: >> On 10/22/2013 12:55 PM, Jonathan Wilkes wrote: >>> 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 >> I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, >> which >> is 64-bit. > > Yes. AFAICT, getting it to work with Cocoa is a matter of revising tkpath to > use the revised TkMacOSXInt.h header functions and structures in the newer > versions of tcl/tk instead of the old ones. There are some hints by looking > at the rest of tk that uses that header and seeing how they changed their > code. > >> >> Your determination is admirable, I just think there are better areas to focus >> your efforts. Last I checked, tkpath is not really maintained. We should >> really be talking about pulling the GUI functions out of the Pd core, then >> people can do things like write a GUI in C++, which will be dramatically >> faster than anything written in Tcl/Tk. > > But "people" aren't going to write a gui for Pd. There is already libpd and > I don't see a bunch of elegant and efficient Pd frontends sprouting up > because of that. (Though I'm sure there are a lot of projects that do cool > things with it.) > > Writing a development environment is a gargantuan task, and testing out > tkpath was literally 3 lines of code added to pdtk_canvas.tcl. Ivica said > getting it to work fully was more effort than that, but the fact that it > supports tk canvas commands allows a lot of improvements to the interface > without having to do a complete rewrite of everything g_*.[ch] > > And of course removing GUI function from the Pd core can be done in addition > to the tkpath improvements. Once you get FUDI messages in both directions, > you'll still have a fully-functional gui dev environment in tcl/tk. > > I'm not convinced there are the resources in the Pd community to fund doing > all the work required to use a different GUI toolkit, plus making all the > redesign and testing speed improvements that another toolkit would bring. > > -Jonathan I'm not proposing that we spend more time on this, but rather that we coordinate efforts and work smartly. Sure, we can keep patching up the existing Pd GUI stuff, and hacking in old Tk code, there has been a lot of that over the years. If we instead invest in the up front work of ripping out the GUI code from pd core, then it becomes drastically easier to write a modern, efficient GUI in whatever toolkit. libpd has not addressed this particular issue, but it will become more valuable if the GUI was truly separate from the core. But the Pd dev community has always been not so good at coordinated efforts. There is a history of lots of effort going into semi-compatible dev forks which mostly die out after a run (pd-devel, desiredata, vibrez, etc. etc.) Perhaps Pd-extended or pd-l2ork will be the next one to die out... .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
...tkpath in pd-l2ork, just like cwiid library is a fork that has more bug fixes and features than any other variant since the core of either packages is not maintained uniformly or at all, so tkpath is very much maintained inside pd-l2ork. There's also on my short-term a todo list to overhaul vanilla gui objects so that they queue their actions rather than requesting the same action multiple times per refresh and bogging down the networked nature of the gui. On Nov 4, 2013 3:52 PM, "Dan Wilcox" wrote: > > On Nov 4, 2013, at 1:35 PM, pd-list-requ...@iem.at wrote: > > But "people" aren't going to write a gui for Pd. There is already libpd > and I don't see a bunch of elegant and efficient Pd frontends sprouting up > because of that. (Though I'm sure there are a lot of projects that do cool > things with it.) > > > The main reason for this is that we haven't pulled out the gui elements > yet. There isn't yet an interface in libpd to edit the object graph and I'm > not sure where the plans are on that. Once it's there I'm sure we could see > some interesting things. I imagine I could add patch editing to PdParty > using Objective-C in about a week or two if I had such an interface. > > I agree with both Han's point that a long term goal of cleanly separating > the gui from the dsp is what we want. At the same time, I agree with > Jonathan in that we shouldn't abandon/neglect what's already here and > working. The overall plan, as far as I know, is once there is a clean > separation the dsp core from the gui, the pd tcl/tk app would then be > updated to use libpd. > > As for when that would happen, who knows? Anyone want to hire Jonathan, > Hans, me, etc at a research lab to do it? I'll be available in the spring :D > > > 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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
On Nov 4, 2013, at 1:35 PM, pd-list-requ...@iem.at wrote: > But "people" aren't going to write a gui for Pd. There is already libpd and > I don't see a bunch of elegant and efficient Pd frontends sprouting up > because of that. (Though I'm sure there are a lot of projects that do cool > things with it.) The main reason for this is that we haven't pulled out the gui elements yet. There isn't yet an interface in libpd to edit the object graph and I'm not sure where the plans are on that. Once it's there I'm sure we could see some interesting things. I imagine I could add patch editing to PdParty using Objective-C in about a week or two if I had such an interface. I agree with both Han's point that a long term goal of cleanly separating the gui from the dsp is what we want. At the same time, I agree with Jonathan in that we shouldn't abandon/neglect what's already here and working. The overall plan, as far as I know, is once there is a clean separation the dsp core from the gui, the pd tcl/tk app would then be updated to use libpd. As for when that would happen, who knows? Anyone want to hire Jonathan, Hans, me, etc at a research lab to do it? I'll be available in the spring :D 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] Help with OSX App minefield
On 11/04/2013 09:51 AM, Hans-Christoph Steiner wrote: On 10/22/2013 12:55 PM, Jonathan Wilkes wrote: 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 I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which is 64-bit. Yes. AFAICT, getting it to work with Cocoa is a matter of revising tkpath to use the revised TkMacOSXInt.h header functions and structures in the newer versions of tcl/tk instead of the old ones. There are some hints by looking at the rest of tk that uses that header and seeing how they changed their code. Your determination is admirable, I just think there are better areas to focus your efforts. Last I checked, tkpath is not really maintained. We should really be talking about pulling the GUI functions out of the Pd core, then people can do things like write a GUI in C++, which will be dramatically faster than anything written in Tcl/Tk. But "people" aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.) Writing a development environment is a gargantuan task, and testing out tkpath was literally 3 lines of code added to pdtk_canvas.tcl. Ivica said getting it to work fully was more effort than that, but the fact that it supports tk canvas commands allows a lot of improvements to the interface without having to do a complete rewrite of everything g_*.[ch] And of course removing GUI function from the Pd core can be done in addition to the tkpath improvements. Once you get FUDI messages in both directions, you'll still have a fully-functional gui dev environment in tcl/tk. I'm not convinced there are the resources in the Pd community to fund doing all the work required to use a different GUI toolkit, plus making all the redesign and testing speed improvements that another toolkit would bring. -Jonathan .hc .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 to move an object by 10 pixels, when I release Shift and then do 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 Wha
Re: [PD] Help with OSX App minefield
On 10/22/2013 12:55 PM, Jonathan Wilkes wrote:
> 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
I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which
is 64-bit.
Your determination is admirable, I just think there are better areas to focus
your efforts. Last I checked, tkpath is not really maintained. We should
really be talking about pulling the GUI functions out of the Pd core, then
people can do things like write a GUI in C++, which will be dramatically
faster than anything written in Tcl/Tk.
.hc
>>
>> .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 to move an object by 10 pixels, when I release
>>> Shift and then do 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)
>> {
>
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 to move an object by 10 pixels, when I release
Shift and then do 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
UNSUBSCRIBE and
Re: [PD] Help with OSX App minefield
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/
.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 to move an object by 10 pixels, when I release
> Shift and then do 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
Re: [PD] Help with OSX App minefield
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.
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 to move an object by 10 pixels, when I release
Shift and then do 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
Re: [PD] Help with OSX App minefield
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.
.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
Re: [PD] Help with OSX App minefield
On 2013-10-09 22:45, 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 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. The linker won't be looking for m_pd.h. It wants the Pd librrary as -lpd Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
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] Help with OSX App minefield
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
