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.