Hi Tim...
I checked this out to see if I could merge my newest changes in... but I can't compile it - I get errors like:
g_io.o(.text+0x706): In function vinlet_perfsimd': /home/msp/pd/attic/cvsdevel-copy/pd/src/g_io.c:156: undefined reference to
copyvec_simd'
(I'm on a P4, running Fedora 2 with its default development environment.)
thanks Miller
On Fri, Nov 05, 2004 at 05:17:55PM +0100, Tim Blechmann wrote:
hi all ...
i created a devel_0_38 branch that is based on miller's 0.38-test7 ...
i would strongly suggest to deprecate devel_0_37 and work on devel_0_38.
most of the features of devel_0_37 are still available and i hope i haven't missed or broke anything ...
have a lot of fun with it ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-announce mailing list PD-announce@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-announce
On Fri, 5 Nov 2004, Miller Puckette wrote:
Hi Tim...
I checked this out to see if I could merge my newest changes in... but
Hi Miller,
I think the best thig would be that Tim is the master of the devel branch and it is his responsibility to put updates from the main branch into the devel branch.
For this to work it would be important that the main branch is up to date.
According to our discussion at pd-conv, we have set up a web page were people can put patches. You can browse through these and decide if you want to include them or not.
http://sourceforge.net/tracker/?group_id=55736&atid=478072
My favorite one is definitely the ALSA sequencer support on Linux. I hope this system will make it easy to collaborate and still ensure good quality of the code.
Guenter
I can't compile it - I get errors like:
g_io.o(.text+0x706): In function
vinlet_perfsimd': /home/msp/pd/attic/cvsdevel-copy/pd/src/g_io.c:156: undefined reference to
copyvec_simd'(I'm on a P4, running Fedora 2 with its default development environment.)
thanks Miller
On Fri, Nov 05, 2004 at 05:17:55PM +0100, Tim Blechmann wrote:
hi all ...
i created a devel_0_38 branch that is based on miller's 0.38-test7 ...
i would strongly suggest to deprecate devel_0_37 and work on devel_0_38.
most of the features of devel_0_37 are still available and i hope i haven't missed or broke anything ...
have a lot of fun with it ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-announce mailing list PD-announce@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-announce
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
For this to work it would be important that the main branch is up to date.
According to our discussion at pd-conv, we have set up a web page were people can put patches. You can browse through these and decide if you want to include them or not.
there is one point i'd like to add here ...
i love the idea of a patch tracker, but some changes are working on the same code ... the best example is the combination of thomas' simd code, vector and array alignment and my threaded soundfiler that needs a threadlock for arrays ... it would be possible to make patches for each feature, but clean patches against the main branch will possibly collide with each other ...
cheers ... tim
On Sat, 6 Nov 2004, Tim Blechmann wrote:
i love the idea of a patch tracker, but some changes are working on the same code ... the best example is the combination of thomas' simd code, vector and array alignment and my threaded soundfiler that needs a threadlock for arrays ... it would be possible to make patches for each feature, but clean patches against the main branch will possibly collide with each other ...
That should be avoided. There are two solutions.
We have to figure out which is the more comfortable way of doing it.
Guenter
OK... I went and updated main (was trying to do them both simultaneously but that didn't work).
Good old "merge" program will fold the changes into devel straightforwardly.
On Sat, Nov 06, 2004 at 12:35:32PM +0100, guenter geiger wrote:
On Fri, 5 Nov 2004, Miller Puckette wrote:
Hi Tim...
I checked this out to see if I could merge my newest changes in... but
Hi Miller,
I think the best thig would be that Tim is the master of the devel branch and it is his responsibility to put updates from the main branch into the devel branch.
For this to work it would be important that the main branch is up to date.
Yes, but I think most of the patches should wait for 0.39... I'm just trying to fix the bugs in 0.38 right now. I hope to get it ready by next week!
cheers Miller
According to our discussion at pd-conv, we have set up a web page were people can put patches. You can browse through these and decide if you want to include them or not.
http://sourceforge.net/tracker/?group_id=55736&atid=478072
My favorite one is definitely the ALSA sequencer support on Linux. I hope this system will make it easy to collaborate and still ensure good quality of the code.
Guenter
A
Yes, but I think most of the patches should wait for 0.39... I'm just trying to fix the bugs in 0.38 right now. I hope to get it ready by next week!
question: does this inlcude bugs reported at sourceforge ? http://sourceforge.net/tracker/?group_id=55736&atid=478070 I mean would it make sense for example to include a patch against main ?
. g
On Sat, 6 Nov 2004, 0001 wrote:
Yes, but I think most of the patches should wait for 0.39... I'm just trying to fix the bugs in 0.38 right now. I hope to get it ready by next week!
question: does this inlcude bugs reported at sourceforge ? http://sourceforge.net/tracker/?group_id=55736&atid=478070 I mean would it make sense for example to include a patch against main ?
I think this would be a good way to do it. Just picking those patches which are actually bug fixes and delaying the others to post 0.38.
If have added a group "bugfix", this way, on the patches web page, you can easily filter out patches which are bugfixes and therefore should probably go into 0.38. (Just put "bugfix" in the Group popup and click "Browse").
Guenter
. g
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
I see the group in the Patches page. I was meaning the Bugs page ... no idea about how it works, but wouldn't this be even easier ?
. g
El 06/11/2004, a las 20:25, guenter geiger escribió:
On Sat, 6 Nov 2004, 0001 wrote:
Yes, but I think most of the patches should wait for 0.39... I'm just trying to fix the bugs in 0.38 right now. I hope to get it ready by next week!
question: does this inlcude bugs reported at sourceforge ? http://sourceforge.net/tracker/?group_id=55736&atid=478070 I mean would it make sense for example to include a patch against
main ?I think this would be a good way to do it. Just picking those patches which are actually bug fixes and delaying the others to post 0.38.
If have added a group "bugfix", this way, on the patches web page, you can easily filter out patches which are bugfixes and therefore should probably go into 0.38. (Just put "bugfix" in the Group popup and click "Browse").
Guenter
. g
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Sat, 6 Nov 2004, 0001 wrote:
I see the group in the Patches page. I was meaning the Bugs page ... no idea about how it works, but wouldn't this be even easier ?
Sorry, your question was if the bugs at the bugs page [1] are going to be fixed ? Lets hope so.
Guenter
[1] http://sourceforge.net/tracker/?group_id=55736&atid=478070
. g
El 06/11/2004, a las 20:25, guenter geiger escribi�:
On Sat, 6 Nov 2004, 0001 wrote:
Yes, but I think most of the patches should wait for 0.39... I'm just trying to fix the bugs in 0.38 right now. I hope to get it ready by next week!
question: does this inlcude bugs reported at sourceforge ? http://sourceforge.net/tracker/?group_id=55736&atid=478070 I mean would it make sense for example to include a patch against main ?
I think this would be a good way to do it. Just picking those patches which are actually bug fixes and delaying the others to post 0.38.
If have added a group "bugfix", this way, on the patches web page, you can easily filter out patches which are bugfixes and therefore should probably go into 0.38. (Just put "bugfix" in the Group popup and click "Browse").
Guenter
. g
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Lets hope so.
ok that didn't sound very convincing. I wanted to make a patch but I found out that u_main.tk doesn't seem to be the same in MAIN than in the OSX release .. is that possible or am I missing something ?
it's something very simple but it never gets into official tree ... the ALT key on OSX!!! I think many people would like to use it. It happens to be called "Option" instead of "Alt"
the fix is easy and harmless here's a quick diff of u_main.tk in Pd-0.38-0test7.app
953,956d952 < bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} < bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y %b 5} < bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y %b 6} < bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W %x %y %b 7} 957a954,965
# Alt key is called Option on the Mac if {$pd_nt == 2} { bind $name.c <Option-Button> {pdtk_canvas_click %W %x %y %b 4} bind $name.c <Option-Shift-Button> {pdtk_canvas_click %W %x
%y %b 5}
bind $name.c <Option-Control-Button> {pdtk_canvas_click %W %x
%y %b 6}
bind $name.c <Option-Control-Shift-Button> {pdtk_canvas_click
%W %x %y %b 7}
} else { bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y
%b 5}
bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y
%b 6}
bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W
%x %y %b 7}
}
977c985,989
if {$pd_nt == 2} { bind $name.c <Option-Key> {pdtk_canvas_altkey %W %K %A} } else { bind $name.c <Alt-Key> {pdtk_canvas_altkey %W %K %A} }
987c999,1004
if {$pd_nt == 2} { bind $name.c <Option-Motion> {pdtk_canvas_motion %W %x %y 4} } else { bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4} }
. g
Hmm... depends where you got the OSX package. Anyway, I put your changes in my home copy; they should show up in "main" later today...
thanks Miller
On Sun, Nov 07, 2004 at 10:10:04PM +0100, 0001 wrote:
Lets hope so.
ok that didn't sound very convincing. I wanted to make a patch but I found out that u_main.tk doesn't seem to be the same in MAIN than in the OSX release .. is that possible or am I missing something ?
it's something very simple but it never gets into official tree ... the ALT key on OSX!!! I think many people would like to use it. It happens to be called "Option" instead of "Alt"
the fix is easy and harmless here's a quick diff of u_main.tk in Pd-0.38-0test7.app
953,956d952 < bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} < bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y %b 5} < bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y %b 6} < bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W %x %y %b 7} 957a954,965
# Alt key is called Option on the Mac if {$pd_nt == 2} { bind $name.c <Option-Button> {pdtk_canvas_click %W %x %y %b
4}
bind $name.c <Option-Shift-Button> {pdtk_canvas_click %W %x
%y %b 5}
bind $name.c <Option-Control-Button> {pdtk_canvas_click %W %x
%y %b 6}
bind $name.c <Option-Control-Shift-Button> {pdtk_canvas_click
%W %x %y %b 7}
} else { bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y
%b 5}
bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y
%b 6}
bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W
%x %y %b 7}
}
977c985,989
< bind $name.c <Alt-Key> {pdtk_canvas_altkey %W %K %A}
if {$pd_nt == 2} { bind $name.c <Option-Key> {pdtk_canvas_altkey %W %K %A} } else { bind $name.c <Alt-Key> {pdtk_canvas_altkey %W %K %A} }
987c999,1004
< bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4}
if {$pd_nt == 2} { bind $name.c <Option-Motion> {pdtk_canvas_motion %W %x %y 4} } else { bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4} }
. g
On Sun, 7 Nov 2004, 0001 wrote:
Lets hope so.
ok that didn't sound very convincing.
Well, I meant it to be convincing. The uncertainity came more from the fact that there might be bugs that we don't know how to fix.
If you send in a patch that fixes a bug it is very likely that it gets applied. This is the whole reasoning behind it. We want to avoid that fixes get lost, and the tracker reminds us what is still to be done and what has been fixed already.
Guenter
I wanted to make a patch but I found out that u_main.tk doesn't seem to be the same in MAIN than in the OSX release .. is that possible or am I missing something ?
it's something very simple but it never gets into official tree ... the ALT key on OSX!!! I think many people would like to use it. It happens to be called "Option" instead of "Alt"
the fix is easy and harmless here's a quick diff of u_main.tk in Pd-0.38-0test7.app
953,956d952 < bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} < bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y %b 5} < bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y %b 6} < bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W %x %y %b 7} 957a954,965
# Alt key is called Option on the Mac if {$pd_nt == 2} { bind $name.c <Option-Button> {pdtk_canvas_click %W %x %y %b 4} bind $name.c <Option-Shift-Button> {pdtk_canvas_click %W %x
%y %b 5}
bind $name.c <Option-Control-Button> {pdtk_canvas_click %W %x
%y %b 6}
bind $name.c <Option-Control-Shift-Button> {pdtk_canvas_click
%W %x %y %b 7}
} else { bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y
%b 5}
bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y
%b 6}
bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W
%x %y %b 7}
}
977c985,989
< bind $name.c <Alt-Key> {pdtk_canvas_altkey %W %K %A}
if {$pd_nt == 2} { bind $name.c <Option-Key> {pdtk_canvas_altkey %W %K %A} } else { bind $name.c <Alt-Key> {pdtk_canvas_altkey %W %K %A} }
987c999,1004
< bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4}
if {$pd_nt == 2} { bind $name.c <Option-Motion> {pdtk_canvas_motion %W %x %y 4} } else { bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4} }
. g
ok then
bug only -> Bugs page bug + patch -> Patches page under group 'bugfix'
. g
El 08/11/2004, a las 1:10, guenter geiger escribió:
On Sun, 7 Nov 2004, 0001 wrote:
Lets hope so.
ok that didn't sound very convincing.
Well, I meant it to be convincing. The uncertainity came more from the fact that there might be bugs that we don't know how to fix.
If you send in a patch that fixes a bug it is very likely that it gets applied. This is the whole reasoning behind it. We want to avoid that fixes get lost, and the tracker reminds us what is still to be done and what has been fixed already.
Guenter
I wanted to make a patch but I found out that u_main.tk doesn't seem to be the same in MAIN than in the OSX release .. is that possible or am I missing something ?
it's something very simple but it never gets into official tree ... the ALT key on OSX!!! I think many people would like to use it. It happens to be called "Option" instead of "Alt"
the fix is easy and harmless here's a quick diff of u_main.tk in Pd-0.38-0test7.app
953,956d952 < bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} < bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y %b 5} < bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y %b 6} < bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W %x %y %b 7} 957a954,965
# Alt key is called Option on the Mac if {$pd_nt == 2} { bind $name.c <Option-Button> {pdtk_canvas_click %W %x %y %b 4} bind $name.c <Option-Shift-Button> {pdtk_canvas_click %W %x
%y %b 5}
bind $name.c <Option-Control-Button> {pdtk_canvas_click %W %x
%y %b 6}
bind $name.c <Option-Control-Shift-Button> {pdtk_canvas_click
%W %x %y %b 7}
} else { bind $name.c <Alt-Button> {pdtk_canvas_click %W %x %y %b 4} bind $name.c <Alt-Shift-Button> {pdtk_canvas_click %W %x %y
%b 5}
bind $name.c <Alt-Control-Button> {pdtk_canvas_click %W %x %y
%b 6}
bind $name.c <Alt-Control-Shift-Button> {pdtk_canvas_click %W
%x %y %b 7}
}
977c985,989
< bind $name.c <Alt-Key> {pdtk_canvas_altkey %W %K %A}
if {$pd_nt == 2} { bind $name.c <Option-Key> {pdtk_canvas_altkey %W %K %A} } else { bind $name.c <Alt-Key> {pdtk_canvas_altkey %W %K %A} }
987c999,1004
< bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4}
if {$pd_nt == 2} { bind $name.c <Option-Motion> {pdtk_canvas_motion %W %x %y 4} } else { bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4} }
. g
Hi devels, just one question about the organisation of cvs development: May i still commit changes to the devel branch myself or am i supposed to post to the patch tracker? I would prefer the former approach because i fear that Tim would have too much work with the patches otherwise, and on the other hand my PD devel checkout would certainly be a mess of patches, sync'd and unsync'd versions.
best greetings, Thomas
----- Original Message ----- From: "guenter geiger" geiger@xdv.org To: msp@ucsd.edu Cc: pd-list@iem.kug.ac.at Sent: Saturday, November 06, 2004 12:35 PM Subject: Re: [PD] Re: [PD-announce] devel_0_38
On Fri, 5 Nov 2004, Miller Puckette wrote:
Hi Tim...
I checked this out to see if I could merge my newest changes in... but
Hi Miller,
I think the best thig would be that Tim is the master of the devel branch and it is his responsibility to put updates from the main branch into the devel branch.
For this to work it would be important that the main branch is up to date.
According to our discussion at pd-conv, we have set up a web page were people can put patches. You can browse through these and decide if you want to include them or not.
http://sourceforge.net/tracker/?group_id=55736&atid=478072
My favorite one is definitely the ALSA sequencer support on Linux. I hope this system will make it easy to collaborate and still ensure good quality of the code.
Guenter
I can't compile it - I get errors like:
g_io.o(.text+0x706): In function `vinlet_perfsimd': /home/msp/pd/attic/cvsdevel-copy/pd/src/g_io.c:156: undefined reference
to `copyvec_simd'
(I'm on a P4, running Fedora 2 with its default development
environment.)
thanks Miller
On Fri, Nov 05, 2004 at 05:17:55PM +0100, Tim Blechmann wrote:
hi all ...
i created a devel_0_38 branch that is based on miller's 0.38-test7 ...
i would strongly suggest to deprecate devel_0_37 and work on
devel_0_38.
most of the features of devel_0_37 are still available and i hope i haven't missed or broke anything ...
have a lot of fun with it ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-announce mailing list PD-announce@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-announce
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Sun, 7 Nov 2004, Thomas Grill wrote:
Hi devels, just one question about the organisation of cvs development: May i still commit changes to the devel branch myself or am i supposed to post to the patch tracker?
the patches are thought to be against millers version. the behaviour of the devel branch will stay the same/ so you commit directly.
If you have a feature implemented in devel that is stable enough/ you might send a patch/ so it can be included easily by miller.
the main idea is to make live as easy as possible for miller to adopt new features and to make clear which changes belong to which feature aso.
Guenter
I would prefer the former approach because i fear that Tim would have too much work with the patches otherwise, and on the other hand my PD devel checkout would certainly be a mess of patches, sync'd and unsync'd versions.
best greetings, Thomas
----- Original Message ----- From: "guenter geiger" geiger@xdv.org To: msp@ucsd.edu Cc: pd-list@iem.kug.ac.at Sent: Saturday, November 06, 2004 12:35 PM Subject: Re: [PD] Re: [PD-announce] devel_0_38
On Fri, 5 Nov 2004, Miller Puckette wrote:
Hi Tim...
I checked this out to see if I could merge my newest changes in... but
Hi Miller,
I think the best thig would be that Tim is the master of the devel branch and it is his responsibility to put updates from the main branch into the devel branch.
For this to work it would be important that the main branch is up to date.
According to our discussion at pd-conv, we have set up a web page were people can put patches. You can browse through these and decide if you want to include them or not.
http://sourceforge.net/tracker/?group_id=55736&atid=478072
My favorite one is definitely the ALSA sequencer support on Linux. I hope this system will make it easy to collaborate and still ensure good quality of the code.
Guenter
I can't compile it - I get errors like:
g_io.o(.text+0x706): In function `vinlet_perfsimd': /home/msp/pd/attic/cvsdevel-copy/pd/src/g_io.c:156: undefined reference
to `copyvec_simd'
(I'm on a P4, running Fedora 2 with its default development
environment.)
thanks Miller
On Fri, Nov 05, 2004 at 05:17:55PM +0100, Tim Blechmann wrote:
hi all ...
i created a devel_0_38 branch that is based on miller's 0.38-test7 ...
i would strongly suggest to deprecate devel_0_37 and work on
devel_0_38.
most of the features of devel_0_37 are still available and i hope i haven't missed or broke anything ...
have a lot of fun with it ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-announce mailing list PD-announce@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-announce
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
just one question about the organisation of cvs development: May i still commit changes to the devel branch myself or am i supposed to post to the patch tracker?
sure ...
I would prefer the former approach because i fear that Tim would have too much work with the patches otherwise, and on the other hand my PD devel checkout would certainly be a mess of patches, sync'd and unsync'd versions.
i think, i'll only try to keep track of the changes to devel_0_38 ... and maybe tag a devel_ version that is known to be stable ...
cheers ... tim
On Nov 7, 2004, at 8:29 AM, Tim Blechmann wrote:
just one question about the organisation of cvs development: May i still commit changes to the devel branch myself or am i supposed to post to the patch tracker?
sure ...
I would prefer the former approach because i fear that Tim would have too much work with the patches otherwise, and on the other hand my PD devel checkout would certainly be a mess of patches, sync'd and unsync'd versions.
i think, i'll only try to keep track of the changes to devel_0_38 ... and maybe tag a devel_ version that is known to be stable ...
Yes! We should definitely be using tagging more. I plan on tagging
for every release I make, tho I am not decided whether beta releases
should be tagged as well, or just final releases. Can anyone think of
the disadvantages of this much tagging?
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it
away to benefit those who profit from scarcity."
-John Gilmore
I checked this out to see if I could merge my newest changes in... but
I can't compile it - I get errors like:
g_io.o(.text+0x706): In function
vinlet_perfsimd': /home/msp/pd/attic/cvsdevel-copy/pd/src/g_io.c:156: undefined reference to
copyvec_simd'
i haven't updated the original build system ... to compile, you can try to use my autobuild system (pd/bootstrap and pd/configure)
i've updated it ... anyway, i hope someone can make a clean mac & cygwin port of the autobuild system, so you can consider to use it as default ...
cheers ... tim