Hi everyone,
Before I completely give up on pd and buy a copy of Max/MSP, I'm going to give compiling pd, so I can fix the things that bug me, one more try.
Can someone who has done so very recently (as in within the last two months) point me to an up-to-date tutorial on compiling under Windows that actually works? Or at the very least tell me which version I should be checking out of CVS (and which CVS repository to get it from).
Thanks,
Damian Stewart a écrit :
Hi everyone,
Before I completely give up on pd and buy a copy of Max/MSP, I'm going to give compiling pd, so I can fix the things that bug me, one more try.
Can someone who has done so very recently (as in within the last two months) point me to an up-to-date tutorial on compiling under Windows that actually works? Or at the very least tell me which version I should be checking out of CVS (and which CVS repository to get it from).
Thanks,
Hi, I've followed this tutorial: http://puredata.org/docs/developer/mingw
I had to correct several errors, it was last month, for example you have to rename d_mayer_ftt.c to d_fft_mayer.c and two other errors, take a look at the source files where the error occurs, and report to the list things that you couldn't find out.
Have fun.
Patco
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
On Nov 9, 2006, at 7:37 PM, Patco wrote:
Damian Stewart a écrit :
Hi everyone,
Before I completely give up on pd and buy a copy of Max/MSP, I'm
going to give compiling pd, so I can fix the things that bug me,
one more try.Can someone who has done so very recently (as in within the last
two months) point me to an up-to-date tutorial on compiling under
Windows that actually works? Or at the very least tell me which
version I should be checking out of CVS (and which CVS repository
to get it from).Thanks,
Hi, I've followed this tutorial: http://puredata.org/docs/developer/mingw
I had to correct several errors, it was last month, for example you
have to rename d_mayer_ftt.c to d_fft_mayer.c and two other errors, take a look at the source files where the
error occurs, and report to the list things that you couldn't find
out.
That howto is tailored to building Pd 0.39.2, hence the broken file
names for newer versions. You can also just download a nightly build:
http://autobuild.puredata.info.
.hc
Have fun.
Patco
______________________________________________________________________ _____ Découvrez une nouvelle façon d'obtenir des réponses à toutes
vos questions ! Profitez des connaissances, des opinions et des
expériences des internautes sur Yahoo! Questions/Réponses http:// fr.answers.yahoo.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
Hans-Christoph Steiner a écrit :
That howto is tailored to building Pd 0.39.2, hence the broken file names for newer versions. You can also just download a nightly build:
http://autobuild.puredata.info.
.hc
Hi, The features list is long! I haven't tried to compile a nightly build yet, but will do it soon, with MY modified version of makefile.mingw, because the one available on the tutorial seems obsolete. Also I've got some questions: I've tried to build pd with using tcl/tk-8.5 sources with no satisfaying results, pd.exe is still linked to wish84.exe, Did anyone successfully built pd with this TCL/TK version? I am also wondering if some ::ix widgets requires tcl/tk-8.5? Thanks a lot for any anwers. PatCo.
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
On Fri, 10 Nov 2006, Patco wrote:
I've tried to build pd with using tcl/tk-8.5 sources with no satisfaying results, pd.exe is still linked to wish84.exe, Did anyone successfully built pd with this TCL/TK version?
When configuring the build of pd, make sure that it detects the right tcl/tk version, and if not, investigate why it is so.
note that devel_0_39 does it in reverse than Miller's: it picks the lowest available version instead of the highest. To make it pick the highest version, you have to edit pd/src/SConscript and replace:
for i in range (0,10):
by
for i in range (9,-1,-1):
so that it counts possible versions downwards.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 10, 2006, at 4:54 AM, Patco wrote:
Hans-Christoph Steiner a écrit :
That howto is tailored to building Pd 0.39.2, hence the broken
file names for newer versions. You can also just download a
nightly build:http://autobuild.puredata.info.
.hc
Hi, The features list is long! I haven't tried to compile a nightly build yet, but will do it soon, with MY modified version of makefile.mingw, because the one
available on the tutorial seems obsolete. Also I've got some questions: I've tried to build pd with using tcl/tk-8.5 sources with no
satisfaying results, pd.exe is still linked to wish84.exe, Did anyone successfully built pd with this TCL/TK version? I am also wondering if some ::ix widgets requires tcl/tk-8.5? Thanks a lot for any anwers. PatCo.
Even better than improving on the crappy makefile.mingw that has been
hacked together by Miller, Carmen, me and probably others, I suggest
you help me get Pd compiling on MinGW using the same ./configure &&
make interface as the other platforms.
I don't think it would be hard, I have already gotten things to
compile properly using ./configure on MinGW, but not everything
worked properly. If there is at least one (even more, more)
committed Windows user that will help out, then we can get the
Windows build more in line with the rest.
Then we can move onto to the other issues.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hi,
Hans-Christoph Steiner a écrit :
Even better than improving on the crappy makefile.mingw that has been hacked together by Miller, Carmen, me and probably others, I suggest you help me get Pd compiling on MinGW using the same ./configure && make interface as the other platforms.
Oh no, one more thing I've just forgotten, sorry it's the second time you tell me.
I don't think it would be hard, I have already gotten things to compile properly using ./configure on MinGW, but not everything worked properly. If there is at least one (even more, more) committed Windows user that will help out, then we can get the Windows build more in line with the rest.
Then we can move onto to the other issues.
That sounds nice. PC.
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Damian Stewart wrote:
Hi everyone,
Before I completely give up on pd and buy a copy of Max/MSP, I'm going to give compiling pd, so I can fix the things that bug me, one more try.
Can someone who has done so very recently (as in within the last two months) point me to an up-to-date tutorial on compiling under Windows that actually works? Or at the very least tell me which version I should be checking out of CVS (and which CVS repository to get it from).
Thanks,
hey,
before spitting on pd, could you consider changing the root of your system?
( and a few brain cells too ? )
saludos, sevy
hey,
before spitting on pd, could you consider changing the root of your system?
( and a few brain cells too ? )
i already knew that ydegoyon would have to mumble something insightful and enlightening after damian's brazen affront. ahhh - what a miserable world that would be without our beloved and brave floss freedom fighters...
it's late and scnr, sven.
@damian (1): max/msp is really worth the money especially if you need a gui @damian (2): what's wrong with the pd-win32 binaries available?
hey sven,
i was just interested in the concept of 'changing brain cells'
and, yeh, why making pd run on windows?
free software on your out-of-the-shop machine, isn't that a contradiction?
but see you one day, mate, sevy
sven wrote:
hey,
before spitting on pd, could you consider changing the root of your system?
( and a few brain cells too ? )
i already knew that ydegoyon would have to mumble something insightful and enlightening after damian's brazen affront. ahhh - what a miserable world that would be without our beloved and brave floss freedom fighters...
it's late and scnr, sven.
@damian (1): max/msp is really worth the money especially if you need a gui @damian (2): what's wrong with the pd-win32 binaries available?
anyway, unhappy pd user,
we don't know exactly what you want buy some licenses if you want and feed the pigs ( those who commercialized miller's ideas )
ciao, sevy
Yves Degoyon wrote:
hey sven,
i was just interested in the concept of 'changing brain cells'
and, yeh, why making pd run on windows?
free software on your out-of-the-shop machine, isn't that a contradiction?
but see you one day, mate, sevy
sven wrote:
hey,
before spitting on pd, could you consider changing the root of your system?
( and a few brain cells too ? )
i already knew that ydegoyon would have to mumble something insightful and enlightening after damian's brazen affront. ahhh - what a miserable world that would be without our beloved and brave floss freedom fighters...
it's late and scnr, sven.
@damian (1): max/msp is really worth the money especially if you need a gui @damian (2): what's wrong with the pd-win32 binaries available?
Yves Degoyon wrote:
and, yeh, why making pd run on windows?
because linux doesn't like either of my external sound devices on my laptop (despite my buying one of them specifically because of its apparently good linux success rate), and certainly doesn't begin to run with the kind of latencies i can get on windows, without halting spectacularly. (yes, i've tried <insert audio-specific distro here>).
Yves Degoyon wrote:
and, yeh, why making pd run on windows?
why have a windows version of something that doesn't run on windows?
Yves Degoyon wrote:
hey sven,
i was just interested in the concept of 'changing brain cells'
and for f*ck's suck, why assume that just because i don't subscribe to your particular political-economic views on software there's something wrong with my brain cells?
sven a écrit :
max/msp is really worth the money especially if you need a gui
Learning how to make a GUI is really worth if we need a GUI. May I ask: how does MaxMSP gives any hint about making a pretty fast GUI?
@damian (2): what's wrong with the pd-win32 binaries available?
We've got many things to tell about it, so let's start a topic about it, anytime.
here's a few examples:
_ limitations of the entries in registry (10 libraries max) _ no compatibility of the last versions with pdvst _ some undocumented set of patches, libraries, and internals _ no compatibility of some externals (pdp, for example that might never be available on win32 but we can try it with dowloading, burning, and booting the last Dynebolic marvel, just for the price of the empty CDrom and internet connection) _ ...
Win32 has it's own limitations anyway, the Windows Midi Driver latency is the best example I think of what we couldn't fix under windows. So using linux on a PC for using fully such things like PD is inevitable. Anyway, it's hard to think that we could use a PC fully with a winOS, without counting all security problems we could encounter on microswift products. So one make with what one has, and most people in pd-list are doing good things, everyone is allowed to put the hands in sources for improving the code. PD core and external developpers are almost always available, I severly think it's not the case with the developpers market products, but I might be wrong? PatCo.
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
sven wrote:
@damian (2): what's wrong with the pd-win32 binaries available?
compile from source 2) my entire rig tends to triple its cpu usage for no apparent reason after a quasi-random length of time, which seems to be a vaguely repeatable error, which I would like to compile from source to figure out 3) line doesn't have a right outlet that it bangs on completion, which I could fix myself if compiling from source; yes I know I could just build an abstraction but that's not the point 4) tooltips on inlets, which i could and would add myself, if i could compile from source 5) just random crashes, which i could try to investigate/fix myself, if i could compile from source (i have a significant amount of commercial software development experience tracking down extremely obscure crashes in c/c++ code) 6) i want to write my own gui objects (to match or exceed those that come with max/msp) but i don't have a pd.lib and since i can't compile from source i can't make my own, so actually i can't write my own gui objects.
basically, i want to use pd, and would be willing to put up with its idiosyncracies if i could compile it myself and make changes i felt were necessary where they were necessary. however, i can't compile it from source, and every time i try i get either shouted at, told that the windows version isn't really supported, or helped for a few steps and then given up on when it becomes clear that it's not a simple newbie problem i'm suffering, and is rather something fundamentally broken about the administration of the windows source.
in the end i realise that i'd much rather be making music, and dealing with this kind of crap really isn't making music.
Damian Stewart a écrit :
sven wrote:
@damian (2): what's wrong with the pd-win32 binaries available?
- midi crashes, which I could figure out and fix for myself, if I
could compile from source 2) my entire rig tends to triple its cpu usage for no apparent reason after a quasi-random length of time, which seems to be a vaguely repeatable error, which I would like to compile from source to figure out 3) line doesn't have a right outlet that it bangs on completion, which I could fix myself if compiling from source; yes I know I could just build an abstraction but that's not the point 4) tooltips on inlets, which i could and would add myself, if i could compile from source 5) just random crashes, which i could try to investigate/fix myself, if i could compile from source (i have a significant amount of commercial software development experience tracking down extremely obscure crashes in c/c++ code) 6) i want to write my own gui objects (to match or exceed those that come with max/msp) but i don't have a pd.lib and since i can't compile from source i can't make my own, so actually i can't write my own gui objects.
basically, i want to use pd, and would be willing to put up with its idiosyncracies if i could compile it myself and make changes i felt were necessary where they were necessary. however, i can't compile it from source, and every time i try i get either shouted at, told that the windows version isn't really supported, or helped for a few steps and then given up on when it becomes clear that it's not a simple newbie problem i'm suffering, and is rather something fundamentally broken about the administration of the windows source.
in the end i realise that i'd much rather be making music, and dealing with this kind of crap really isn't making music.
Hello, have you tried to run pd through a debugger for targeting errors? (and also help yourself and pd communauty to fix). Why do you want to fix all errors by yourself? Some features you are requiring are available on a version called Desire Data (inlet/outlet tooltips). There are dozens of people that could help, but they couldn't anything without having a clue about occuring problems, that might also come from "bad patching" or "bad understanding" of some objects. And finally you have a very big bunch of choices for building your own GUI: extract from nightly build README: " graph "hide name" flag controllable from dialog "installation mode" - turn off Pd window, accelerators, menu bars, scrollbars " You can run pd with -nogui and use a GUI made with TKinter, XUL, or PHP-GTK, or ... you can build nice GUI also with using MiXed/Toxy, and pd data structure is a nice way for building many kinds of user interfaces.
I've tried some stand alones made with the payware version, they are not very efficient.
Many pd options and tips are not documented enough, but what about giving some advices instead of (sorry) whining about it? PatCo.
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Patco wrote:
Hello, have you tried to run pd through a debugger for targeting errors? (and also help yourself and pd communauty to fix).
if i'm going to go to the trouble of doing that i'd like to be able to edit the source so i can recompile and figure out what's going on myself. from a development point of view, 'aaargh it crashed, here's a stacktrace' is usually only slightly less useless than 'aargh it crashed' in my experience. sure you can find where your pointer is null or whatever but that isn't going to tell you /why/ that particular pointer is null, which is where the work is.
Why do you want to fix all errors by yourself?
because (correct me if I'm wrong) no-one else seems willing to. because the feeling i get from the community here is that even if i do write an incredibly detailed and amazing bug report /no-one is going to care because it's the windows version/.
midi on windows is my main sticking point. if people care about the the windows version, why is midi on windows /still/ 'dangerous'? surely midi control is fundamental to serious performance-based usage of a program like pd?
ok, i'll try something in my next post.
Some features you are requiring are available on a version called Desire Data (inlet/outlet tooltips).
yes, which I need to compile myself, it would seem.
There are dozens of people that could help, but they couldn't anything without having a clue about occuring problems, that might also come from "bad patching" or "bad understanding" of some objects. And finally you have a very big bunch of choices for building your own GUI:
i mean building my own GUI objects, which working along with the pd program itself. i was wanting to experiment with using directx rather than tcl/tk for rendering graphics to get some real high-performance stuff going on, which is going to require building in c, which as i understand it requires a pd.lib.
and pd data structure is a nice way for building many kinds of user interfaces.
except it's *incredibly* slow if you get a decent amount of data on-screen.
if i drag a [gate] object around the gui window, or save a patch containing a [gate], the [gate] object is saved as a different type depending on what the last message to its left inlet was. (0==text, 1==object, 2==msg, 3==numberbox, ...)
i'm running pd-extended-0.39.2-extended-2006-11-08-windowsxp
attached is a patch that demonstrates the bug.
Damian Stewart a écrit :
i'm running pd-extended-0.39.2-extended-2006-11-08-windowsxp
attached is a patch that demonstrates the bug.
I've just replaced [gate 3] with zexy/[demux 0 1 2 3] it should be similar, but without making bugs. [gate] comes from cyclone, right? cyclone from win32 pd-extended has bugs, maybe you should use the version from original site? PatCo.
#N canvas 0 0 462 312 12; #X obj 127 31 metro 1000; #X msg 243 9 bang; #X obj 264 57 metro 400; #X obj 262 95 counter 0 10; #X obj 146 95 + 1; #X obj 124 60 counter 0 3; #X obj 191 149 demux 0 1 2 3; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 6 1; #X connect 4 0 6 0; #X connect 5 0 4 0;
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
On Sat, 11 Nov 2006, Damian Stewart wrote:
if i drag a [gate] object around the gui window, or save a patch containing a [gate], the [gate] object is saved as a different type depending on what the last message to its left inlet was. (0==text, 1==object, 2==msg, 3==numberbox, ...)
That looks like a problem of using a very old m_pd.h, so old that t_text would have a different number of fields in it, such that writing to t_gate's x_open would instead write to t_text's te_type.
However, I don't see any further evidence of this (no old m_pd.h in that directory); and it certainly wouldn't explain that thing about moving the object around: [gate] does not define anything that reacts to the object being moved.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 10 Nov 2006, Mathieu Bouchard wrote:
On Sat, 11 Nov 2006, Damian Stewart wrote:
if i drag a [gate] object around the gui window, or save a patch containing a [gate], the [gate] object is saved as a different type depending on what the last message to its left inlet was. (0==text, 1==object, 2==msg, 3==numberbox, ...)
That looks like a problem of using a very old m_pd.h,
[...]
However, I don't see any further evidence of this
I just thought: could it be a difference in the memory alignment options of some externals vs pd itself? something that could change the sizeof(t_text) without having a different m_pd.h. However it still wouldn't explain the problem with dragging around, unless different parts of pd have different alignment settings (!).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 10, 2006, at 9:19 AM, Mathieu Bouchard wrote:
On Fri, 10 Nov 2006, Mathieu Bouchard wrote:
On Sat, 11 Nov 2006, Damian Stewart wrote:
if i drag a [gate] object around the gui window, or save a patch
containing a [gate], the [gate] object is saved as a different
type depending on what the last message to its left inlet was.
(0==text, 1==object, 2==msg, 3==numberbox, ...)That looks like a problem of using a very old m_pd.h,
[...]
However, I don't see any further evidence of this
I just thought: could it be a difference in the memory alignment
options of some externals vs pd itself? something that could change
the sizeof(t_text) without having a different m_pd.h. However it
still wouldn't explain the problem with dragging around, unless
different parts of pd have different alignment settings (!).
Krzysztof thought it might be related to -mms-bitfields option in
MinGW. I think the bugs have occured using with and without that
field. Currently, cyclone and family are set to compile without -mms-
bitfields.
There is no way to peace, peace is the way. -A.J. Muste
On Fri, 10 Nov 2006, Hans-Christoph Steiner wrote:
Krzysztof thought it might be related to -mms-bitfields option in MinGW. I think the bugs have occured using with and without that field. Currently, cyclone and family are set to compile without -mms-bitfields.
I think that for that kind of problem it could be a good idea to have a new call in m_pd.h in which an external states to pd what its interpretation of m_pd.h's structs is, so that pd can detect problems. e.g. m_pd.h could contain a statement-like macro and a function decl:
#define pd_begin_setup() pd_make_sure(sizeof(t_text)) EXTERN pd_make_sure(size_t sizeof_text);
And then every external would call pd_begin_setup() as soon as it enters its own setup function, in order to make sure that the external is binary-compatible.
I'm not 100% satisfied with the idea, but I think that it could really help categorize some bugs better. This case seems to be win32-only, though, so I don't think that I can reproduce it (?). Are there similar options on Linux for struct alignment? If there are, they must be super rare.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 12 Nov 2006, Mathieu Bouchard wrote:
I think that for that kind of problem it could be a good idea to have a new call in m_pd.h in which an external states to pd what its interpretation of m_pd.h's structs is, so that pd can detect problems. e.g. m_pd.h could contain a statement-like macro and a function decl: #define pd_begin_setup() pd_make_sure(sizeof(t_text)) EXTERN pd_make_sure(size_t sizeof_text);
Actually, we don't need pd to check it for us, and we don't even need to call a function to get the size of a class. E.g.
#include <stdio.h> #include "m_pd.h" #include "m_imp.h"
extern t_class *text_class;
void sanity_setup (void) { post("t_text is %d bytes according to pd", text_class->c_size); post("t_text is %d bytes according to me", sizeof(t_text)); }
So if text_class->c_size != sizeof(t_text) then the externals compiled with the same options as this external will not be compatible with the pd that loaded -lib sanity.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
This sounds similar to bugs I was getting with Cyclone objects.
However, on my PD, this patch creates a bug with the [counter] objects
objects with the dashed box arround them).
But there may be a better cyclone in the newest pd-extended test from what I hear?
~David
On 11/10/06, Damian Stewart damian@frey.co.nz wrote:
if i drag a [gate] object around the gui window, or save a patch containing a [gate], the [gate] object is saved as a different type depending on what the last message to its left inlet was. (0==text, 1==object, 2==msg, 3==numberbox, ...)
i'm running pd-extended-0.39.2-extended-2006-11-08-windowsxp
attached is a patch that demonstrates the bug.
-- Damian Stewart +64 27 305 4107
f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed
#N canvas 0 0 462 312 12; #X obj 127 31 metro 1000; #X msg 243 9 bang; #X obj 264 57 metro 400; #X obj 262 95 counter 0 10; #X obj 146 95 + 1; #X obj 124 60 counter 0 3; #X obj 191 149 gate 3; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 6 1; #X connect 4 0 6 0; #X connect 5 0 4 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Wow, that's a crazy bug. If you are still willing, I'd like to help
you get things building on Windows/MinGW. And the best place to post
good bug reports like this is the bugtracker:
http://puredata.org/dev/bugtracker
.hc
On Nov 10, 2006, at 6:24 AM, Damian Stewart wrote:
if i drag a [gate] object around the gui window, or save a patch
containing a [gate], the [gate] object is saved as a different type
depending on what the last message to its left inlet was. (0==text,
1==object, 2==msg, 3==numberbox, ...)i'm running pd-extended-0.39.2-extended-2006-11-08-windowsxp
attached is a patch that demonstrates the bug.
-- Damian Stewart +64 27 305 4107
f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed
#N canvas 0 0 462 312 12; #X obj 127 31 metro 1000; #X msg 243 9 bang; #X obj 264 57 metro 400; #X obj 262 95 counter 0 10; #X obj 146 95 + 1; #X obj 124 60 counter 0 3; #X obj 191 149 gate 3; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 6 1; #X connect 4 0 6 0; #X connect 5 0 4 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
Wow, that's a crazy bug. If you are still willing, I'd like to help you get things building on Windows/MinGW. And the best place to post good bug reports like this is the bugtracker:
done
Hi,
Is there any object in PD that can recognize and customize a Gamepad (USB input)? As in Max/MSP with the HI?
Thanks,
Carlos Caires
Hi Carlos~
You can use the external HID library for this (on Mac/Gnu/Linux). This can be found easily by installing hc's Pd-extended.
But you'll have to format the data from the joystick for many things (like object rotations) by using things like counter objects and metros (at lest from my experience!).
~Kyle
On 11/15/06, Carlos Caires ccaires@porto.ucp.pt wrote:
Hi,
Is there any object in PD that can recognize and customize a Gamepad (USB input)? As in Max/MSP with the HI?
Thanks,
Carlos Caires
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[hid] is th object you're looking for.
On Wed, 15 Nov 2006 18:37:10 +0000 Carlos Caires ccaires@porto.ucp.pt wrote:
Hi,
Is there any object in PD that can recognize and customize a Gamepad (USB input)? As in Max/MSP with the HI?
Thanks,
Carlos Caires
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
And if you want to use J. Sarlo's [joystick] object (win32 only), consider using my updated version of it, which adds the use of the point-of-view hat. http://web.media.mit.edu/~dmerrill/sw/joystick.zip -David M.
Frank Barknecht wrote:
Hallo, padawan12 hat gesagt: // padawan12 wrote:
[hid] is th object you're looking for.
Or J. Sarlo's older [joystick] object.
Ciao
On Windows, there is also [hidin].
.hc
On Nov 16, 2006, at 11:06 PM, David Merrill wrote:
And if you want to use J. Sarlo's [joystick] object (win32 only),
consider using my updated version of it, which adds the use of the
point-of-view hat. http://web.media.mit.edu/~dmerrill/sw/joystick.zip -David M.Frank Barknecht wrote:
Hallo, padawan12 hat gesagt: // padawan12 wrote:
[hid] is th object you're looking for.
Or J. Sarlo's older [joystick] object.
Ciao
-- MIT Media Lab dmerrill@media.mit.edu
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Damian Stewart a écrit :
because (correct me if I'm wrong) no-one else seems willing to. because the feeling i get from the community here is that even if i do write an incredibly detailed and amazing bug report /no-one is going to care because it's the windows version/.
Have you got an example in your archive?
midi on windows is my main sticking point. if people care about the the windows version, why is midi on windows /still/ 'dangerous'? surely midi control is fundamental to serious performance-based usage of a program like pd?
I don't, I have not experienced crashes caused by MIDI in pd, anyway, I am trying to not use MIDI under windows for reasons explained in last post, and pd has nothing to do with encountered problem with this obsolete protocol.
i mean building my own GUI objects, which working along with the pd program itself.
What's the efficiency problems with Toxy/[widget]? It works good on my machines (loads fast, doesn't lag...) and it's possible to make very nice things with, like a movie viewer, an explorer fork, only ix has done some work with it, but this work seems to be a good start, for making something pretty, fast and usefull.
i was wanting to experiment with using directx rather than tcl/tk for rendering graphics to get some real high-performance stuff going on,
Really? Would you be interested about using DELPHI for this project?
which is going to require building in c, which as i understand it requires a pd.lib.
Well I am still a newbee and doesn't understand why pd.lib is required for building in C.
PatCo.
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Patco wrote:
midi on windows is my main sticking point. if people care about the the windows version, why is midi on windows /still/ 'dangerous'? surely midi control is fundamental to serious performance-based usage of a program like pd?
I don't, I have not experienced crashes caused by MIDI in pd, anyway, I am trying to not use MIDI under windows for reasons explained in last post, and pd has nothing to do with encountered problem with this obsolete protocol.
most consumer-level control surfaces (novation, are midi devices. to the best of my knowledge there are very few control surfaces that use osc, for the main reason that osc is several orders of magnitude more difficult to implement on a microcontroller chip of the kind used to drive music control devices. despite its limitations (7-bit fader/pot control, ugh) midi is far from obsolete, unfortunately.
i mean building my own GUI objects, which working along with the pd program itself.
What's the efficiency problems with Toxy/[widget]? It works good on my machines (loads fast, doesn't lag...) and it's possible to make very nice things with, like a movie viewer, an explorer fork, only ix has done some work with it, but this work seems to be a good start, for making something pretty, fast and usefull.
toxy looks great in all the screenshots i've seen, but it crashes and/or refuses to load on my machine. toxy not working was one of the reasons i wanted to get compile from source working..
i was wanting to experiment with using directx rather than tcl/tk for rendering graphics to get some real high-performance stuff going on,
Really? Would you be interested about using DELPHI for this project?
i don't really know delphi as a language, but i don't see why i should need to use delphi as i already can do c.
which is going to require building in c, which as i understand it requires a pd.lib.
Well I am still a newbee and doesn't understand why pd.lib is required for building in C.
you need the .lib to link against, so that your external and pd can talk to each other.
Damian Stewart a écrit :
most consumer-level control surfaces (novation, are midi devices. to the best of my knowledge there are very few control surfaces that use osc, for the main reason that osc is several orders of magnitude more difficult to implement on a microcontroller chip of the kind used to drive music control devices. despite its limitations (7-bit fader/pot control, ugh) midi is far from obsolete, unfortunately.
I would be curious to see it's possible to replace expensive design of usual control surfaces, with things like arduino.
toxy looks great in all the screenshots i've seen, but it crashes and/or refuses to load on my machine. toxy not working was one of the reasons i wanted to get compile from source working..
Same problem, you should provide the dll (alpha15) on the official site.
i don't really know delphi as a language, but i don't see why i should need to use delphi as i already can do c.
It was just an idea, I've found so easy to make something quick with DELPHI's turboPascal, there is a free workshop for transforming C into Pascal language. http://www.freedownloadscenter.com/Programming/Delphi_Tools_and_Components/C...
which is going to require building in c, which as i understand it requires a pd.lib.
Well I am still a newbee and doesn't understand why pd.lib is required for building in C.
you need the .lib to link against, so that your external and pd can talk to each other.
Ah I see, pd.lib would come when pd will be successfully compiled, that what's happened in here, I bet the list will help if you have errors during compilation with mingw. PC.
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Damian Stewart wrote:
most consumer-level control surfaces (novation, are midi devices. to the best of my knowledge there are very few control surfaces that use osc, for the main reason that osc is several orders of magnitude more difficult to implement on a microcontroller chip of the kind used to drive music control devices. despite its limitations (7-bit fader/pot control, ugh) midi is far from obsolete, unfortunately.
MIDI has 14-bit controllers...
Martin
On Nov 10, 2006, at 6:37 AM, Patco wrote:
Damian Stewart a écrit :
because (correct me if I'm wrong) no-one else seems willing to.
because the feeling i get from the community here is that even if
i do write an incredibly detailed and amazing bug report /no-one
is going to care because it's the windows version/.Have you got an example in your archive?
midi on windows is my main sticking point. if people care about
the the windows version, why is midi on windows /still/
'dangerous'? surely midi control is fundamental to serious
performance-based usage of a program like pd?I don't, I have not experienced crashes caused by MIDI in pd,
anyway, I am trying to not use MIDI under windows for reasons
explained in last post, and pd has nothing to do with encountered problem with this
obsolete protocol.i mean building my own GUI objects, which working along with the
pd program itself.What's the efficiency problems with Toxy/[widget]? It works good on
my machines (loads fast, doesn't lag...) and it's possible to make
very nice things with, like a movie viewer, an explorer fork, only
ix has done some work with it, but this work seems to be a good
start, for making something pretty, fast and usefull.i was wanting to experiment with using directx rather than tcl/tk
for rendering graphics to get some real high-performance stuff
going on,Really? Would you be interested about using DELPHI for this project?
FYI: the Windows builds include GriPD, which allows you to build GUIs
in GTK.
which is going to require building in c, which as i understand it
requires a pd.lib.Well I am still a newbee and doesn't understand why pd.lib is
required for building in C.
When building an object, it will definitely rely on code in Pd.
Windows needs to know where to find that code, so it uses pd.lib to
check that out. But that's only need with MSVC, MinGW can just use
the DLL.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hans-Christoph Steiner a écrit :
FYI: the Windows builds include GriPD, which allows you to build GUIs in GTK.
Euh, hum, have you tried it? My CPU really doesn't like GriPD (amd64), so am I. PC.
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
On 11/10/06, Damian Stewart damian@frey.co.nz wrote:
midi on windows is my main sticking point. if people care about the the windows version, why is midi on windows /still/ 'dangerous'? surely midi control is fundamental to serious performance-based usage of a program like pd?
Is MIDI "really" broken? Because despite those messages, I've never had problems running MIDI with PD. Perhaps this message is not current? For instance, I got great results feeding generative stuff from PD into Ableton which I used to host some VST's. I left this program running all day and night and it was still running great in the morning*. (There are things that mysteriously crash PD all the time though).
One reason NOT to use Max/MSP on the PC: it seems to run much better on Mac than on PC last I saw. For example, on PC, in order to get a video stream from a webcam into jitter, it requires a third party app that converts the video to a quickstream format. And guess what, a typical Logitech webcam off the shelf, just doesn't work with this third party app. The same webcam worked great, and immediately, under PD+gem for me on win32.
~David
On Fri, 2006-11-10 at 23:33 +1300, Damian Stewart wrote:
i was wanting to experiment with using directx rather than tcl/tk for rendering graphics to get some real high-performance stuff going on,
whoooaaa!!!! that would be a reason for me to switch back to windows when doing pd. or would there be a way in linux to have a fast gui as well? (not that i plan to implement it :-) )
and pd data structure is a nice way for building many kinds of user interfaces.
except it's *incredibly* slow if you get a decent amount of data on-screen.
indeed
cheers roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Fri, 10 Nov 2006, Roman Haefeli wrote:
whoooaaa!!!! that would be a reason for me to switch back to windows when doing pd. or would there be a way in linux to have a fast gui as well? (not that i plan to implement it :-) )
I think that a portable solution would be to use Tcl/Gtk instead of Tcl/Tk, and then build a thin Tk<->Gtk emulation layer until Pd can run.
I haven't tried Tcl/Gtk (aka Gnocl). Also I don't remember whether it fully supports libgnomecanvas-2.so, which would be required in order to support enough Tk for Pd's needs.
I can't try it anytime soon, so if someone wants to pick up that task I would very much appreciate it.
I'd suggest first checking whether a Tk<->Gtk emulation layer already exists, and then try to team up with other (non-pd) people who think that Tk is too slow.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Patco wrote:
Why do you want to fix all errors by yourself?
i don't, i just would like the ability to fix the errors which i can feel are going to be easy to fix right /now/ so that i can continue working on the patch for my live gig which is tomorrow night. for example.
here's what gdb says loading numbers.pd from the rradical examples directory:
(gdb) run Starting program: D:\art\pd\bin/pd.exe ---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit--- Program received signal SIGSEGV, Segmentation fault. 0x7801036e in strncpy () from D:\WINNT\system32\msvcrt.dll (gdb) bt #0 0x7801036e in strncpy () from D:\WINNT\system32\msvcrt.dll #1 0x000007ff in ?? () #2 0x0022cd40 in ?? () #3 0x00000001 in ?? () #4 0x675412c8 in tosymbol_parse () from D:\art\pd\extra\cyclone\tosymbol.dll #5 0x000007ff in ?? () #6 0x0000006c in ?? () #7 0x0022cae8 in ?? () #8 0x0022cabc in ?? () #9 0x00000800 in ?? () #10 0x00955660 in ?? () #11 0x0022cd40 in ?? () #12 0x0022cd40 in ?? () #13 0x00955548 in ?? () #14 0x675415a4 in tosymbol_anything () from D:\art\pd\extra\cyclone\tosymbol.dll #15 0x0022cd40 in ?? () #16 0x00000001 in ?? () #17 0x00000800 in ?? () #18 0x67546040 in tosymbol_class () #19 0x00000018 in ?? () #20 0x00000018 in ?? () #21 0x00410000 in ?? () ---Type <return> to continue, or q <return> to quit--- #22 0x00000000 in ?? () from #23 0x00000020 in ?? () #24 0x00943329 in ?? () #25 0x00000001 in ?? () #26 0x67384c70 in pd_typedmess () from D:\art\pd\bin\pd.dll #27 0x00955660 in ?? () #28 0x00943329 in ?? () #29 0x00000001 in ?? () #30 0x0022cd40 in ?? () #31 0x0041015c in ?? () #32 0x00000005 in ?? () #33 0x00e80003 in ?? () #34 0x00959b70 in ?? () #35 0x0094f100 in ?? () #36 0x00000004 in ?? () #37 0x00fd5ff0 in ?? () #38 0x00000001 in ?? () #39 0x00000010 in ?? () #40 0x004101b0 in ?? () #41 0x00fd5fc8 in ?? () #42 0x00fd5fd0 in ?? () #43 0x00000028 in ?? () #44 0x00fd5fe8 in ?? () ---Type <return> to continue, or q <return> to quit--- #45 0x0022c744 in ?? () #46 0x7ffde000 in ?? () #47 0x0022c974 in ?? () #48 0x00000000 in ?? () from #49 0x0022c900 in ?? () #50 0x0022c920 in ?? () #51 0x00000001 in ?? () #52 0x0022c984 in ?? () #53 0x77fb57c6 in ?? () #54 0x00410608 in ?? () #55 0x77fb5589 in ?? () #56 0x00000000 in ?? () from #57 0x00410000 in ?? () #58 0x00000000 in ?? () from #59 0x00000010 in ?? () #60 0x004101a0 in ?? () #61 0x0094a948 in ?? () #62 0x0094a950 in ?? () #63 0x00000028 in ?? () #64 0x0094a968 in ?? () #65 0x0022c794 in ?? () #66 0x7ffde000 in ?? () #67 0x0022c9c4 in ?? () ---Type <return> to continue, or q <return> to quit--- #68 0x77f98191 in ?? () #69 0x0094a950 in ?? () #70 0x0095cfc0 in ?? () #71 0x0022cd40 in ?? () #72 0x00000001 in ?? () #73 0x00943329 in ?? () #74 0x67386b87 in outlet_anything () from D:\art\pd\bin\pd.dll #75 0x00000002 in ?? () #76 0x0022cb44 in ?? () #77 0x77f98191 in ?? () #78 0x00943329 in ?? () #79 0x00000001 in ?? () #80 0x0022cd40 in ?? () #81 0x00418df8 in ?? () #82 0x67384c70 in pd_typedmess () from D:\art\pd\bin\pd.dll #83 0x0095ae50 in ?? () #84 0x00943329 in ?? () #85 0x00000001 in ?? () #86 0x0022cd40 in ?? () #87 0x00000000 in ?? () from #88 0x674186e0 in mstack.0 () #89 0x004128d0 in ?? () #90 0x67384c70 in pd_typedmess () from D:\art\pd\bin\pd.dll ---Type <return> to continue, or q <return> to quit--- #91 0x009746c0 in ?? () #92 0x6740fc00 in _data_end__ () #93 0x6740f960 in _data_end__ () #94 0x00960ea8 in ?? () #95 0x00000001 in ?? () #96 0x674186e0 in mstack.0 () #97 0x004128d0 in ?? () #98 0x67384c70 in pd_typedmess () from D:\art\pd\bin\pd.dll #99 0x00974748 in ?? () #100 0x00960ea8 in ?? () #101 0x00000001 in ?? () #102 0x674186e0 in mstack.0 () #103 0x50000169 in ?? () #104 0x00000000 in ?? () from #105 0x0022c9f0 in ?? () #106 0x0022ca10 in ?? () #107 0x00000000 in ?? () from #108 0x00000005 in ?? () #109 0x00000005 in ?? () #110 0x00000004 in ?? () #111 0x0022ca80 in ?? () #112 0x00000000 in ?? () from #113 0x0022ca10 in ?? () ---Type <return> to continue, or q <return> to quit--- #114 0x0022ca30 in ?? () #115 0x00000010 in ?? () #116 0x00000000 in ?? () from #117 0x0022ca20 in ?? () #118 0x0022ca40 in ?? () #119 0x0022caa4 in ?? () #120 0x00000000 in ?? () from #121 0x0022ca30 in ?? () #122 0x0022ca50 in ?? () #123 0x78033ab0 in modf () #124 0x3f800000 in ?? () #125 0x00000000 in ?? () from #126 0x67386a1f in outlet_float () from D:\art\pd\bin\pd.dll #127 0x00000000 in ?? () from #128 0x67386b07 in outlet_list () from D:\art\pd\bin\pd.dll #129 0x00e83a08 in ?? () #130 0x3f800000 in ?? () #131 0x42000000 in ?? () #132 0x00000000 in ?? () from #133 0x00942c02 in ?? () #134 0x00e91e30 in ?? () #135 0x3f800000 in ?? () #136 0x67383850 in bindlist_float () from D:\art\pd\bin\pd.dll ---Type <return> to continue, or q <return> to quit--- #137 0x00000001 in ?? () #138 0x00a22cf8 in ?? () #139 0x009729f8 in ?? () #140 0x0099d938 in ?? () #141 0x3f800000 in ?? () #142 0x67386a1f in outlet_float () from D:\art\pd\bin\pd.dll #143 0x00942c00 in ?? () #144 0x00a28d40 in ?? () #145 0x00942bd8 in ?? () #146 0x674186d8 in mstack.0 () #147 0x0099d528 in ?? () #148 0x67389053 in binbuf_eval () from D:\art\pd\bin\pd.dll #149 0x00946880 in ?? () (gdb)
aaand here's what it says loading minipli-test.pd: (gdb) run Starting program: D:\art\pd\bin/pd.exe ---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit--- Program received signal SIGSEGV, Segmentation fault. 0x675412fd in tosymbol_parse () from D:\art\pd\extra\cyclone\tosymbol.dll (gdb) bt #0 0x675412fd in tosymbol_parse () from D:\art\pd\extra\cyclone\tosymbol.dll #1 0x000007ff in ?? () #2 0x00410178 in ?? () #3 0x00410100 in ?? () #4 0x00990ef8 in ?? () #5 0x67544000 in ?? () #6 0x00961fa8 in ?? () #7 0x674186f0 in mstack.0 () #8 0x674186f0 in mstack.0 () #9 0x00961e90 in ?? () #10 0x675415a4 in tosymbol_anything () from D:\art\pd\extra\cyclone\tosymbol.dll #11 0x674186f0 in mstack.0 () #12 0x00000001 in ?? () #13 0x00000800 in ?? () #14 0x67546040 in tosymbol_class () #15 0x0095b768 in ?? () #16 0x00956498 in ?? () #17 0x00000002 in ?? () #18 0x0093e270 in ?? () #19 0x00000001 in ?? () #20 0x0094c3a0 in ?? () #21 0x00000001 in ?? () ---Type <return> to continue, or q <return> to quit--- #22 0x67384c70 in pd_typedmess () from D:\art\pd\bin\pd.dll #23 0x00961fa8 in ?? () #24 0x0094c3a0 in ?? () #25 0x00000001 in ?? () #26 0x674186f0 in mstack.0 () #27 0x0095bdf8 in ?? () #28 0x00956498 in ?? () #29 0x00000002 in ?? () #30 0x0095ba68 in ?? () #31 0x0a277269 in ?? () #32 0x00000000 in ?? () from #33 0x0098ee03 in ?? () #34 0x0095ba60 in ?? () #35 0x00000003 in ?? () #36 0x67408814 in s_anything () #37 0x0095b9d0 in ?? () #38 0x673c6247 in pack_bang () from D:\art\pd\bin\pd.dll #39 0x67408814 in s_anything () #40 0x00000003 in ?? () #41 0x0095ba60 in ?? () #42 0x00000028 in ?? () #43 0x00000000 in ?? () from #44 0x0022c5f0 in ?? () ---Type <return> to continue, or q <return> to quit--- #45 0x0022c610 in ?? () #46 0x00956498 in ?? () #47 0x00000000 in ?? () from #48 0x00000000 in ?? () from #49 0x67386a8f in outlet_symbol () from D:\art\pd\bin\pd.dll #50 0x77fb57c6 in ?? () #51 0x00410608 in ?? () #52 0x77fb5589 in ?? () #53 0x0095bf80 in ?? () #54 0x00000000 in ?? () from #55 0x673c3d79 in pdsymbol_bang () from D:\art\pd\bin\pd.dll #56 0x0095bbf0 in ?? () #57 0x00956498 in ?? () #58 0x00410000 in ?? () #59 0x6738691b in outlet_bang () from D:\art\pd\bin\pd.dll #60 0x00000001 in ?? () #61 0x0095bce8 in ?? () #62 0x00967f58 in ?? () #63 0x674186f0 in mstack.0 () #64 0x00000001 in ?? () #65 0x0094c3a0 in ?? () #66 0x67386b87 in outlet_anything () from D:\art\pd\bin\pd.dll #67 0x00000001 in ?? () ---Type <return> to continue, or q <return> to quit--- #68 0x009569b8 in ?? () #69 0x674186e8 in mstack.0 () #70 0x0094c3a0 in ?? () #71 0x00000001 in ?? () #72 0x674186f0 in mstack.0 () #73 0x00418df8 in ?? () #74 0x67384c70 in pd_typedmess () from D:\art\pd\bin\pd.dll #75 0x0095fc60 in ?? () #76 0x0094c3a0 in ?? () #77 0x00000001 in ?? () #78 0x674186f0 in mstack.0 () #79 0x0095bca0 in ?? () #80 0x00949fb8 in ?? () #81 0x00965710 in ?? () #82 0x6738691b in outlet_bang () from D:\art\pd\bin\pd.dll #83 0x0095c0d8 in ?? () #84 0x0095c0d0 in ?? () #85 0x673c809c in trigger_list () from D:\art\pd\bin\pd.dll #86 0x0022c6f8 in ?? () (gdb)
Damian Stewart a écrit :
here's what gdb says loading numbers.pd from the rradical examples directory:
Hi thanks for the gdb lines
Attrached is a version of OSCprepend that doesn't need fromsymbol tosymbol, and then doesn't crashes.
PC.
#N canvas 0 0 454 304 12; #X msg 304 166 set $1%s; #X obj 150 83 inlet; #X obj 304 86 inlet; #X obj 157 349 outlet; #X obj 304 117 symbol; #X obj 150 226 makefilename $1%s; #X obj 154 253 list; #X obj 160 283 list prepend; #X obj 216 251 t b a; #X obj 105 112 list split 1; #X obj 150 155 l2s; #X obj 165 313 list trim; #X connect 0 0 5 0; #X connect 1 0 9 0; #X connect 2 0 4 0; #X connect 4 0 0 0; #X connect 5 0 8 0; #X connect 6 0 7 0; #X connect 7 0 11 0; #X connect 8 0 6 0; #X connect 8 1 7 1; #X connect 9 0 10 0; #X connect 9 1 6 1; #X connect 10 0 5 0; #X connect 11 0 3 0;
Patco wrote:
Damian Stewart a écrit :
here's what gdb says loading numbers.pd from the rradical examples directory:
Hi thanks for the gdb lines
Attrached is a version of OSCprepend that doesn't need fromsymbol tosymbol, and then doesn't crashes.
cheers, now i get another problem:
Program received signal SIGSEGV, Segmentation fault. 0x78001cf7 in strlen () from D:\WINNT\system32\msvcrt.dll (gdb) bt #0 0x78001cf7 in strlen () from D:\WINNT\system32\msvcrt.dll #1 0x042115f6 in pool_setup () from d:\art\pd\extra\l2s.dll #2 0x00009a9f in ?? () #3 0x00000020 in ?? () #4 0x00000000 in ?? () from #5 0x673d377a in alist_list () from d:\art\pd\bin\pd.dll #6 0x03c40c70 in ?? () (gdb)
Damian Stewart a écrit :
now i get another problem:
Program received signal SIGSEGV, Segmentation fault. 0x78001cf7 in strlen () from D:\WINNT\system32\msvcrt.dll (gdb) bt #0 0x78001cf7 in strlen () from D:\WINNT\system32\msvcrt.dll #1 0x042115f6 in pool_setup () from d:\art\pd\extra\l2s.dll #2 0x00009a9f in ?? () #3 0x00000020 in ?? () #4 0x00000000 in ?? () from #5 0x673d377a in alist_list () from d:\art\pd\bin\pd.dll #6 0x03c40c70 in ?? () (gdb)
Ah, sorry, just replace [l2s] with [symbol] correction is attached, it's now fully internal. PC.
#N canvas 0 0 458 308 12; #X msg 304 166 set $1%s; #X obj 150 83 inlet; #X obj 304 86 inlet; #X obj 157 349 outlet; #X obj 304 117 symbol; #X obj 150 226 makefilename $1%s; #X obj 154 253 list; #X obj 160 283 list prepend; #X obj 216 251 t b a; #X obj 105 112 list split 1; #X obj 165 313 list trim; #X obj 150 154 symbol; #X msg 152 25 list test one; #X obj 292 328 print; #X connect 0 0 5 0; #X connect 1 0 9 0; #X connect 2 0 4 0; #X connect 4 0 0 0; #X connect 5 0 8 0; #X connect 6 0 7 0; #X connect 7 0 10 0; #X connect 8 0 6 0; #X connect 8 1 7 1; #X connect 9 0 11 0; #X connect 9 1 6 1; #X connect 10 0 3 0; #X connect 10 0 13 0; #X connect 11 0 5 0; #X connect 12 0 9 0;
Hallo, Patco hat gesagt: // Patco wrote:
Ah, sorry, just replace [l2s] with [symbol] correction is attached, it's now fully internal.
There is a purepd-OSCprepend in list-abs as well.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 10 Nov 2006, Patco wrote:
Damian Stewart a écrit :
- tooltips on inlets, which i could and would add myself, if i could
compile from source
Some features you are requiring are available on a version called Desire Data (inlet/outlet tooltips).
No, DesireData doesn't support the inlet/outlet tooltips. devel_0_39 does. DesireData only has dummy tooltips which, while nicer-looking, don't do what they're supposed to do, because I've not ported that part of pd yet.
I've tried some stand alones made with the payware version, they are not very efficient.
Hmm, what's the payware version?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard a écrit :
On Fri, 10 Nov 2006, Patco wrote:
I've tried some stand alones made with the payware version, they are not very efficient.
Hmm, what's the payware version?
I've confused the issue with replacing "MAXmsp" by "payware". So, I've tried some win32 standalone MAX patches, and they were very slow at loading, and didn't work very well, but I didn't try many different ones, those problems might come from developpers mistakes rather than MAX itself. PatCo.
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
On Fri, 10 Nov 2006, Patco wrote:
Mathieu Bouchard a écrit :
On Fri, 10 Nov 2006, Patco wrote:
I've tried some stand alones made with the payware version, they are not very efficient.
Hmm, what's the payware version?
I've confused the issue with replacing "MAXmsp" by "payware".
For almost all practical purposes, it's better nowadays to think of MAX and Pd as separately evolving programs, which are mutually incompatible in the details but still largely compatible in the ideas.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Well, hopefully you can ignore the flamebait and we can have a
fruitful discussion here. Let's get you compiling, if you follow the
MinGW HOWTO, then post whenever you have a problem, I think we can
get you compiling without too much difficulty. What is the last
place that didn't work?
On Nov 10, 2006, at 4:38 AM, Damian Stewart wrote:
sven wrote:
@damian (2): what's wrong with the pd-win32 binaries available?
- midi crashes, which I could figure out and fix for myself, if I
could compile from source 2) my entire rig tends to triple its cpu usage for no apparent
reason after a quasi-random length of time, which seems to be a
vaguely repeatable error, which I would like to compile from source
to figure out
These ones are always the hardest to find, but if you can find a way
to trigger it, it'll be much easier to fix.
- line doesn't have a right outlet that it bangs on completion,
which I could fix myself if compiling from source; yes I know I
could just build an abstraction but that's not the point
What's wrong with an abstraction? Bang-on-complete does sound like
it might be useful, but that doesn't have to be implemented in C.
- tooltips on inlets, which i could and would add myself, if i
could compile from source
There is the tooltips patch out there, Miller wasn't opposed to
including it, he just didn't like the way the current one was
implemented. Günter said it would not be too hard to fix the
tooltips patch so that Miller wouldn't object, but I don't remember
the details. There is some discussion in the patch tracker about it.
- just random crashes, which i could try to investigate/fix
myself, if i could compile from source (i have a significant amount
of commercial software development experience tracking down
extremely obscure crashes in c/c++ code)
Let's get you compiling then! It would be awesome if we got some
bugs fixed.
- i want to write my own gui objects (to match or exceed those
that come with max/msp) but i don't have a pd.lib and since i can't
compile from source i can't make my own, so actually i can't write
my own gui objects.
AFAIK, you don't need pd.lib to compile with MinGW. Using MSVC, you
just have to compile one, its the .lib version of pd.dll.
.hc
basically, i want to use pd, and would be willing to put up with
its idiosyncracies if i could compile it myself and make changes i
felt were necessary where they were necessary. however, i can't
compile it from source, and every time i try i get either shouted
at, told that the windows version isn't really supported, or helped
for a few steps and then given up on when it becomes clear that
it's not a simple newbie problem i'm suffering, and is rather
something fundamentally broken about the administration of the
windows source.in the end i realise that i'd much rather be making music, and
dealing with this kind of crap really isn't making music.-- Damian Stewart +64 27 305 4107
f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
- my entire rig tends to triple its cpu usage for no apparent reason
after a quasi-random length of time, which seems to be a vaguely repeatable error, which I would like to compile from source to figure out
These ones are always the hardest to find, but if you can find a way to trigger it, it'll be much easier to fix.
this looks like a denormal bug (in the CPU rather than in pd) does it help if you add some very low (unhearable) noise?
mfg.asdr IOhannes
On Nov 11, 2006, at 12:07 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
- my entire rig tends to triple its cpu usage for no apparent
reason after a quasi-random length of time, which seems to be a vaguely repeatable error, which I would like to compile from source to
figure outThese ones are always the hardest to find, but if you can find a
way to trigger it, it'll be much easier to fix.this looks like a denormal bug (in the CPU rather than in pd) does it help if you add some very low (unhearable) noise?
I thought this was largely fixed in Pd, is there code that still have
that problem?
Damian, which CPU does your machine have?
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
I thought this was largely fixed in Pd, is there code that still have that problem?
even if it is fixed in Pd itself, a lot of external objects could be the cause of troubles with denormals. (e.g. i know that iemlib uses code to avoid denormal problems in recursive structures; otoh, i know that zexy does not have code for denormals (though i cannot think of a zexy object that could cause such problems _on itself_)
mf.adsr IOhannes
Hans-Christoph Steiner wrote:
Damian, which CPU does your machine have?
it's a p4-m (NOT a pentium-M)
i haven't used the patch in question in ages and to be fair haven't really noticed too many other issues.. except for the one time i tried to live-code a patch with a *lot* of VU objects, which was not such a good idea in the first place anyway.
Yves Degoyon wrote:
hey,
before spitting on pd, could you consider changing the root of your system?
( and a few brain cells too ? )
saludos, sevy
well, here's one reason why i'm giving up.
On Fri, 10 Nov 2006, Damian Stewart wrote:
Yves Degoyon wrote:
hey, before spitting on pd, could you consider changing the root of your system? ( and a few brain cells too ? )
well, here's one reason why i'm giving up.
Even though many of us don't want to use ms-windows, and many of us would rather have others not use ms-windows, and some of us even make jokes about ms-windows, no-one else than Degoyon has reached that level of sophistication and diplomacy about it.
So, what I want say is, please don't mind that kind of post, just skip over it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
well, i must say the first agressive message was not mine, but like, 'pd is shit - i will buy a serious software'
i just said ok for this, but i didn't know you really tried on linux, so it's a pity your usb card doesn't work, could you give more details? maybe someone here knows how to fix it.
i personaly stopped supporting windows, but that's only my choice.
sevy
alright,
I have to say, for the most part I agree with Yves.
If a user 'needs software right now for his/her gig tomorrow night' it might actually be better to spend money on something like MaxMSP rather than chasing down countless bugs on such a horrible build system like MinGW on a proprietary box like MS-Windows.
Did you pay your $195 license fee? Microsoft has their eye on you.... remember the EULA you clicked before installing anything? That could land you in a whole mess of legal trouble if you don't watch what you do very closely... Rather than insult the free software efforts and donated time of countless people it might be better in this case to simply spend the money on the product that assuredly works within the time you need it by so, as you say, you can have the maximum time dedicated to making music.
The rationale? Well, someone somewhere gets paid a LOT of money to perfect things like the Max GUI objects to work on Windows. Last time I checked, no one gets paid in this way for developing Pd. Sure maybe matju or Hans get paid some money by some interested party to have GEM support in GridFlow or Hans gets paid to build the pd-extended distribution on every *nix there is, but the point is - Your time is also worth money.
So you can either spend some money to buy a commercial product that has
been endlessly debugged to 'perform right now for what you need it for
at this moment without issues' or you can spend your own time donating
fixes and chasing bugs that will no doubt help others along the way in
the future, in your similar situation.
Personally I find trying to compile things on Windows is like traveling through a sewer. Sure, you get to your destination all right but at the end when its over you say to yourself "did I really have to go through all that just now??? Boy I smell bad"
./d5
On Nov 10, 2006, at 8:32 AM, Yves Degoyon wrote:
well, i must say the first agressive message was not mine, but like, 'pd is shit - i will buy a serious software'
i just said ok for this, but i didn't know you really tried on linux, so it's a pity your usb card doesn't work, could you give more details? maybe someone here knows how to fix it.
i personaly stopped supporting windows, but that's only my choice.
sevy
Unfortunately, MaxMSP does not run that well on Windows. I think I just recounted how PD+Gem runs a webcam on PC, that won't run with Max, for example. So without Pure Data, one is really stuck with programs like Reaktor and Synthedit on PC. (I highly recommend Synthedit, btw, one can develop a basic VST very quickly.) I guess for visuals, you'd have vvvv as the primary choice.
Pure Data actually has the potential to run well on PC, and it just needs more win developers. Those of you who hate windows should just get over the fact that this is CROSS PLATFORM software. Let me just say for the record, when PD does work, it works just fine on PC. It is not the nightmare many people imply, it is simply underdeveloped.
Many of us don't use PD because "it's free software" - I use it primarily because I don't know of any alternative besides running Max on a Macintosh, and Macs are prohibitively expensive. It can do stuff no other software can do. (Well ChucK is looking like an interesting contender actually...)
If and when PD becomes "Linux and Mac only" it would be fine to tell windows users they are out of luck. But it seems out of line to say that users shouldn't run a cross-platform software on one of the platforms that it is supposed to run on.
~David
On 11/10/06, day 5 day5ive@gmail.com wrote:
alright,
I have to say, for the most part I agree with Yves.
If a user 'needs software right now for his/her gig tomorrow night' it might actually be better to spend money on something like MaxMSP rather than chasing down countless bugs on such a horrible build system like MinGW on a proprietary box like MS-Windows.
Did you pay your $195 license fee? Microsoft has their eye on you.... remember the EULA you clicked before installing anything? That could land you in a whole mess of legal trouble if you don't watch what you do very closely... Rather than insult the free software efforts and donated time of countless people it might be better in this case to simply spend the money on the product that assuredly works within the time you need it by so, as you say, you can have the maximum time dedicated to making music.
The rationale? Well, someone somewhere gets paid a LOT of money to perfect things like the Max GUI objects to work on Windows. Last time I checked, no one gets paid in this way for developing Pd. Sure maybe matju or Hans get paid some money by some interested party to have GEM support in GridFlow or Hans gets paid to build the pd-extended distribution on every *nix there is, but the point is - Your time is also worth money.
So you can either spend some money to buy a commercial product that has been endlessly debugged to 'perform right now for what you need it for at this moment without issues' or you can spend your own time donating fixes and chasing bugs that will no doubt help others along the way in the future, in your similar situation.
Personally I find trying to compile things on Windows is like traveling through a sewer. Sure, you get to your destination all right but at the end when its over you say to yourself "did I really have to go through all that just now??? Boy I smell bad"
./d5
On Nov 10, 2006, at 8:32 AM, Yves Degoyon wrote:
well, i must say the first agressive message was not mine, but like, 'pd is shit - i will buy a serious software'
i just said ok for this, but i didn't know you really tried on linux, so it's a pity your usb card doesn't work, could you give more details? maybe someone here knows how to fix it.
i personaly stopped supporting windows, but that's only my choice.
sevy
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 10 Nov 2006, David Powers wrote:
Unfortunately, MaxMSP does not run that well on Windows. I think I just recounted how PD+Gem runs a webcam on PC,
I'd rather have the name "PC" not being used as a synonymous for "Windows", because some use "PC" computers with something else than Windows.
Some people would also object to the use of "PC" to mean "IBM PC", but some object to still using the name "IBM PC" on the grounds that on average in the last decade there's been a lot more IBM in a Macintosh than in a so-called "IBM PC". At least the "Macintoshes are personal computers too!" issue is becoming moot, as Macintoshes become a lot closer to the hardware commonly called PC.
Many of us don't use PD because "it's free software" - I use it primarily because I don't know of any alternative besides running Max on a Macintosh, and Macs are prohibitively expensive.
The price difference isn't anywhere near what it used to be... (but it won't make me switch away from PC hardware).
If and when PD becomes "Linux and Mac only" it would be fine to tell windows users they are out of luck. But it seems out of line to say that users shouldn't run a cross-platform software on one of the platforms that it is supposed to run on.
It's a matter of who's saying it. Don't think of the pd community as one big gestalt. If you want a unified and official opinion from above, choose the marketing department of your favourite corporation.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Yves Degoyon wrote:
well, i must say the first agressive message was not mine, but like, 'pd is shit - i will buy a serious software'
dude, i never said 'pd is shit'. i think pd is awesome, i just don't think it's for me.
i just said ok for this, but i didn't know you really tried on linux, so it's a pity your usb card doesn't work, could you give more details?
maybe when i can be bothered pissing around with it again. last time it swallowed two full days of my life that i'm never going to get back.
On Mon, 13 Nov 2006, Damian Stewart wrote:
maybe when i can be bothered pissing around with it again. last time it swallowed two full days of my life that i'm never going to get back.
That's a rather crude way to do the accounting of your time. How can you be so sure that you didn't do or understand anything in those two days that is going to be useful later on? At this point, you just don't know.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada