Tim Blechmann wrote:

...

well, but i don't want to install the devel-version; i only need it for testing (developing) purposes; the installed version should be plain stable...

well, due to the memory locking bugs in stable_ and the missing sse denormal handling, i wouldn't recommend to run stable_ atm i've posted the patches quite some time ago ... but the haven't been included in stable_

well, i don't want to be rude and i highly appreciate all the memory/simd-stuff you are putting into pd but: i prefer i version of pd that compiles, installs and loads correctly even if it has some minor performance issues; i have never encountered memory_locking bugs within pd myself (except for the famous hard freeze of Gem when using "-rt" on linux; but this is a bug in nvidia's drivers as i have found out)

...

and furthermore this does not explain, why the tk does not work (i had the same problems)

devel_ has changes in the initializing api. i implemented the feature of giving the font name as startup flag ... the problem is general is the way, pd starts the gui ... i haven't found a way to improve this, though ...

no, i was rather referring to not finding the installed header files. (and then it took me quite some time to find out where i had to add the additional includes without re-running configure)

mfg.lod.qwe IOhannes

Tim Blechmann wrote:

...

i prefer i version of pd that compiles, installs and loads correctly even if it has some minor performance issues; i have never encountered memory_locking bugs within pd myself (except for the famous hard freeze of Gem when using "-rt" on linux; but this is a bug in nvidia's drivers as i have found out)

well, unlikely, but possible ... see man malloc man mlockall

yes, i did that.

it is just, that everything i have found on the web regarding this problem (hard freeze with an openGL application that uses page locking) was refering to nvidia's drivers. redhat keeps closing this bug report, as "this is due to nvidia's drivers" (this is not a quote)

some tests have shown, that with pd/Gem it is really the memory-locking that kills pd (it goes up to 100% and becomes unkillable), and i guess the re-prioritizing makes this application lock a system lock.

the problem occurs when a glxWindow is created.

i really think it is an nvidia-driver problem (but of course i would be happy if not and the problem is solvable from here)

...

no, i was rather referring to not finding the installed header files. (and then it took me quite some time to find out where i had to add the additional includes without re-running configure)

hm ... what exactly are you refering to? the only problem i'm aware of is the pd.tk path problem ...

compile-time problems. when i tried to bootstrap.sh... pd would refuse to compile, because tk.h could not be found. debian installs tk.h into /usr/include/tcl<X>.<Y>/

i had no problem at runtime (but i have not opened any property-box or whatsoever)

m,fg.as.dr IOhannes

the thing that you reported this to me today, and the autobuild system is few monthes old, tells me that too little people are using devel_. and most devel_ users are on linux ...

my comments on trying to use devel_0_38 were hidden ina CVS message:

hi tim i tried to make tim_0_38 work properly for that windows volctl~ you asked about.. but patching to ix_0_38 , pd.ini won't load: . open: No such file or directory . No such file or directory and toxy is broken and the gui spews errors like this a lot: . Pd: buffer space wasn't sufficient for long GUI string so, you can try. :D it compiles at least..(and http://whats-your.name/pd/ix038.patch works fine with miller_0_39 (CVS HEAD))

also, it froze for several seconds when opening patches, which seemed strange (of course they never opened properly due to the half-drawn GUI...) however even wtih millers PA19-ASIO the audio worked...

i even think that providing precompiled releases of devel_ from time to time would improve the user feedback ...

also, completely unrelated. if we've got to undo the midi revolution, why do the gui objects default to a 0-127 range, instead of 0.0-1.0 or something?

hm ... i never really dealt with the preset system, except once i had to remove an invalid string from the registry that crashed pd ... can you try to clean pd's registry entries?

the new registry stuff is broken - well maybe not in devel - every time i set something in the new 'settings' editor, it comes up garbled next launch. in addition an .ini file isnt destroyed upon moving to another machine or user or reinstalling the OS.. - had to patch millers version and copy over s_path.c...since my .pdrc/.ini patch included one of yours for commenting entries..

the audio issue is possibly another issue ... got to think about this one ...

oh yeah, the audio works great. basically if the gui works properly i can take a look at fixing the other stuff (.ini / making sure the new build system works in mingw..) but as it is, its kinda borked..

btw, is there a possibility to check, whether page locking has been enabled by an application ?

hm ... good question ... the only way i know is the return value of mlockall...

definitely (and sadly) true. it seems, that you and thomas g. are the only ones.

well, maybe two or three more people ;-) the problem is, that a difference in the api might result difficulties for external developers ... some of my externals will only work with devel, since they are using the fifo, idle-callback or simd/runtime dispatching api... also thomas's flext uses the timestap for garray graphic updates and the idle callbacks (well, at least flext always compiles against stable)

...

i even think that providing precompiled releases of devel_ from time to time would improve the user feedback ...

depends; i tend to think that devel is meant for2 devel'opers. (but probably, stable is meant for horses)

yes and no ... devel_ is usually usable. there are only short times every once in a while, that it won't compile or run. unlike development branches of other projects devel_ is supposed to be usable ... of course this isn't possible ... this is why i think that both tagging "stable" versions of devel_ (something i haven't done, yet) and providing binaries definitely makes sense...

good night ... tim

compile-time problems. when i tried to bootstrap.sh... pd would refuse to compile, because tk.h could not be found. debian installs tk.h into /usr/include/tcl<X>.<Y>/

all right ... i just changed the autoconf script ... can you please test it and let me know, if it works or not?

thanks ... tim

but by copying the cold from the old configure to the new one, don't we polute it again ?

sure ... but for the first it works ...

t