hey there,
i have suddenly started getting an error similar to one that came up on this list last year, but different.
after running a patch of mine (which makes use of many externals, including iemlib, ext13 and d_mp3), i close pd (it doesn't seem to matter how i close it, ctrl-c, file->quit or close-box on the main pd window), and then future attempts to open pd (any patch / no patch) get the following error:
$ pd
rcfile option = -path /usr/local/lib/pd/externs
rcfile option = -path /home/pix/sound/pd/lib
rcfile option = -path /usr/local/lib/iemlib/abs
rcfile option = -lib zexy
rcfile option = -lib iemgui
rcfile option = -lib iemlib1
rcfile option = -lib ext13
rcfile option = -lib d_mp3
rcfile option = -frags 5
rcfile option = -font 10
successfully opened /dev/dsp write-only
error: failed to open MIDI ports; continuing without MIDI.
connecting stream socket: Connection refused (111)
(ignore the midi error, i dont have midi)...
the similar error last year was about not having the loopback interface installed, i have this (i know because pd works the first time). so far, the only way i know to remedy this situation is to reboot. this is pretty inconvenient as you can imagine... and under linux... rebooting just seems wrong :)
there don't seem to be any processes lying around, so i'm wondering what it is doing to my system?
pix.
we had the same problems here, and the workaround we found out, was to downgrade to kernel-2.4.3 (this of course only works, if you are currently working on kernel-2.4.4 )
but on the other hand, this is no real solution either (though better than rebooting all the time, i guess)
mfg.fd.asd IOhannes
On Wed, 16 May 2001 17:17:01 +0200 (CEST) Johannes M Zmoelnig zmoelnig@iem.kug.ac.at wrote:
we had the same problems here, and the workaround we found out, was to downgrade to kernel-2.4.3 (this of course only works, if you are currently working on kernel-2.4.4 )
hehe.. got it in one. thats what you get for version-chasing :)
but on the other hand, this is no real solution either (though better than rebooting all the time, i guess)
well, 2.4.4 didnt fix anything i was hoping it would fix so dropping back to 2.4.3 is no drama. thanks!
pix.
On Wed, 16 May 2001, Johannes M Zmoelnig wrote:
we had the same problems here, and the workaround we found out, was to downgrade to kernel-2.4.3 (this of course only works, if you are currently working on kernel-2.4.4 )
but on the other hand, this is no real solution either (though better than rebooting all the time, i guess)
mhm, what if it is a bug in the kernel ? ... then downgrading seems to be *the* solution, I mean, the same socket connection code did run for years, under SGI, even under Windows
Guenter
just in case, nobody noticed:
kernel-2.4.5 does not have this problem any more, so you can savely upgrade again...
mfg.fdsa.sadf IOhannes
Johannes M Zmoelnig wrote:
we had the same problems here, and the workaround we found out, was to downgrade to kernel-2.4.3 (this of course only works, if you are currently working on kernel-2.4.4 )
but on the other hand, this is no real solution either (though better than rebooting all the time, i guess)
mfg.fd.asd IOhannes
hi,
i currently thinking about possibilities about live performance gem setups. i never used gem in a live situation before, i just was working with it at home. maybe there are some people on the list with some experience about it. i think this could be a interesting discussion anyway.
tim boykets approach i guess was using a video machine (nogui) for gem and another machine for the gui to controll it.
has anybody tried it with two graphikcards, to use one screen for the gui and the other for the videooutput ?
would it be possible in this case to run the screens on different resolutions, because in case i want to run gem only in 640*480, because i want to convert it to composit video afterwards anyway ?
what about cards with an additional analog videoout, can i put a different screen on the analog video out or is it just the same image then on my screen, or could i / do i have to use an additional analog video out card in this case ?
are there any additional possibilities ?
thx 4 input
erich
I read:
maybe there are some people on the list with some experience about it.
though I'm not one of them I know for sure that there are :)
tim boykets approach i guess was using a video machine (nogui) for gem and another machine for the gui to controll it.
I don't remember if it was him, but someone mentioned taking a laptop for the audio and just a good 3d card fir gem and rely on the venue to provide a reasonably fast machine.
has anybody tried it with two graphikcards, to use one screen for the gui and the other for the videooutput ?
I tried two gfx cards but not with gem, but that shouldn't be a problem if you use the right cards XFree4 can do it, NT is said to do it but I personally don't use m$ products
would it be possible in this case to run the screens on different resolutions, because in case i want to run gem only in 640*480, because i want to convert it to composit video afterwards anyway ?
definitely yes
what about cards with an additional analog videoout, can i put a different screen on the analog video out or is it just the same image then on my screen, or could i / do i have to use an additional analog video out card in this case ?
depends, these cards are commonly called dual headed, most modern laptops come with this type though I haven't seen this working under linux yet, works on windows though.
are there any additional possibilities ?
since mark danks mentioned the ps2 I can't get the idea out of my head having a decent subnotebook and a ps1 in my rucksack and use the ps with linux as the gem machine ;)
cheers
x
hi, i'm using gem for live performancees a lot..
- nvidia Geforce GTS (great performance)
- vga-convertor
- interface on a labtop (netsend/netreceive)
works great!
klaus
On Tue, 5 Jun 2001 rat@telecoma.net wrote:
hi,
i currently thinking about possibilities about live performance gem setups. i never used gem in a live situation before, i just was working with it at home. maybe there are some people on the list with some experience about it. i think this could be a interesting discussion anyway.
tim boykets approach i guess was using a video machine (nogui) for gem and another machine for the gui to controll it.
has anybody tried it with two graphikcards, to use one screen for the gui and the other for the videooutput ?
would it be possible in this case to run the screens on different resolutions, because in case i want to run gem only in 640*480, because i want to convert it to composit video afterwards anyway ?
what about cards with an additional analog videoout, can i put a different screen on the analog video out or is it just the same image then on my screen, or could i / do i have to use an additional analog video out card in this case ?
are there any additional possibilities ?
thx 4 input
erich
Hi,
I'm trying to compile externs using Visual C++ 6.
I've managed to resolve most things, but am still getting:
unresolved external symbol _garray_class unresolved external symbol _s_signal
from the linker. Which libs do I need to link to to resolve these? I've linked already to all the libs that I can find in the Pd distribution.
nick
Dr Nick Fells, Music Department, University of Glasgow, Tel: +44 (0) 141-330 4096 Glasgow G12 8QQ Fax: +44 (0) 141-330 3518 UK. http://www.music.gla.ac.uk/~nick
On Wed, 6 Jun 2001, Nick Fells wrote:
Hi,
I'm trying to compile externs using Visual C++ 6.
I've managed to resolve most things, but am still getting:
unresolved external symbol _garray_class unresolved external symbol _s_signal
from the linker. Which libs do I need to link to to resolve these? I've linked already to all the libs that I can find in the Pd distribution.
It is more likely that the symbols are not exported. Is it the ggee externals ?
There are several occurences of &s_signal, and you can replace them by gensym("signal")
Try it first with signal/exp~.c and look if a dll will be produced. signal/exp~.dll
If you succeed I will change all occurences of that, and yes, the garray_class is only used in fofsynth, which is only of very limited use at the moment.
Guenter
Hi Guenter,
No, it's not ggee, it's my own externz for doing granular sampling of an input signal. They compiled under Linux no problem, but I'm a total Windoze compilation novice. I had some assistance from a pro win programmer, which was extremely useful, but these last unresolved symbols we just couldn't pin down.
However, I will give ggee a try once I get time.
Nick
guenter geiger wrote:
On Wed, 6 Jun 2001, Nick Fells wrote:
Hi,
I'm trying to compile externs using Visual C++ 6.
I've managed to resolve most things, but am still getting:
unresolved external symbol _garray_class unresolved external symbol _s_signal
from the linker. Which libs do I need to link to to resolve these? I've linked already to all the libs that I can find in the Pd distribution.
It is more likely that the symbols are not exported. Is it the ggee externals ?
There are several occurences of &s_signal, and you can replace them by gensym("signal")
Try it first with signal/exp~.c and look if a dll will be produced. signal/exp~.dll
If you succeed I will change all occurences of that, and yes, the garray_class is only used in fofsynth, which is only of very limited use at the moment.
Guenter
Hi Nick,
THese are in "pd.lib" (along with 100s of other symbols you need as well... I don't knpw why you'd only get complaints about those two...)
I checked and "pique.c" uses garray_class. The makefile says,
PDNTLIB = $(PDNTLDIR)\libc.lib
$(PDNTLDIR)\oldnames.lib
$(PDNTLDIR)\kernel32.lib
\ftp\pd\bin\pd.lib
and you might have to adjust the path to "pd.lib" there. (This is assuming you use "nmake" to compile. I don't know how it works in the Visual Studio GUI mess.)
cheers Miller
On Wed, Jun 06, 2001 at 05:41:46PM +0100, Nick Fells wrote:
Hi,
I'm trying to compile externs using Visual C++ 6.
I've managed to resolve most things, but am still getting:
unresolved external symbol _garray_class unresolved external symbol _s_signal
from the linker. Which libs do I need to link to to resolve these? I've linked already to all the libs that I can find in the Pd distribution.
nick
Dr Nick Fells, Music Department, University of Glasgow, Tel: +44 (0) 141-330 4096 Glasgow G12 8QQ Fax: +44 (0) 141-330 3518 UK. http://www.music.gla.ac.uk/~nick
Thanks Miller, Guenter, I take it from your comments and those of others on the list VC GUI is not the way to go (it is a mess - full of nasty micros**t-eze). Didn't know about nmake but will look into it (as I said, a Windoze compilation novice - give me unix any day)
Nick
Miller Puckette wrote:
Hi Nick,
THese are in "pd.lib" (along with 100s of other symbols you need as well... I don't knpw why you'd only get complaints about those two...)
I checked and "pique.c" uses garray_class. The makefile says,
PDNTLIB = $(PDNTLDIR)\libc.lib
$(PDNTLDIR)\oldnames.lib
$(PDNTLDIR)\kernel32.lib
\ftp\pd\bin\pd.liband you might have to adjust the path to "pd.lib" there. (This is assuming you use "nmake" to compile. I don't know how it works in the Visual Studio GUI mess.)
cheers Miller
On Wed, Jun 06, 2001 at 05:41:46PM +0100, Nick Fells wrote:
Hi,
I'm trying to compile externs using Visual C++ 6.
I've managed to resolve most things, but am still getting:
unresolved external symbol _garray_class unresolved external symbol _s_signal
from the linker. Which libs do I need to link to to resolve these? I've linked already to all the libs that I can find in the Pd distribution.
nick
Dr Nick Fells, Music Department, University of Glasgow, Tel: +44 (0) 141-330 4096 Glasgow G12 8QQ Fax: +44 (0) 141-330 3518 UK. http://www.music.gla.ac.uk/~nick
hi,
thx klaus and ck for their input.
i currently try to get the dri working for a matrox g400 and jumped into some problems are their some people out there who are working with a g400 ?
thx
erich
On Tue, 5 Jun 2001, klaus voltmer wrote:
hi, i'm using gem for live performancees a lot..
- nvidia Geforce GTS (great performance)
- vga-convertor
- interface on a labtop (netsend/netreceive)
works great!
klaus
On Tue, 5 Jun 2001 rat@telecoma.net wrote:
hi,
i currently thinking about possibilities about live performance gem setups. i never used gem in a live situation before, i just was working with it at home. maybe there are some people on the list with some experience about it. i think this could be a interesting discussion anyway.
tim boykets approach i guess was using a video machine (nogui) for gem and another machine for the gui to controll it.
has anybody tried it with two graphikcards, to use one screen for the gui and the other for the videooutput ?
would it be possible in this case to run the screens on different resolutions, because in case i want to run gem only in 640*480, because i want to convert it to composit video afterwards anyway ?
what about cards with an additional analog videoout, can i put a different screen on the analog video out or is it just the same image then on my screen, or could i / do i have to use an additional analog video out card in this case ?
are there any additional possibilities ?
thx 4 input
erich
rat@telecoma.net hat gesagt: // rat@telecoma.net wrote:
i currently try to get the dri working for a matrox g400 and jumped into some problems are their some people out there who are working with a g400 ?
Yes, me. And I have dri running. What's going wrong?
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
yo_ just yesterday i was getting the very same err.
i.e. works once, then after 1 time quit it wont anymore. then i did a new kernel with some of the socket/packet filtering options enabled, and after that it didnt even work once. ;(
anyhow, it does thou work fine if i start it remotely via X.
i also did seem to notice that there indeed _was_ a pd-gui process still hanging around after the first attempt, which would not let itself be killed. hence reboot.
it is the same with miller 0.32P6 version and gue's p1 ..
it only happened (so far) on a brand-newly installed debian unstable, so i thought the err was somewhere to be sought in the Xfree4 or whereever unthroughseeable system quaqua ..
wait 2 days and do another dist-upgrade or on systems where it works at the mom refrain from being on the edge softwarewise. ;)
|i have suddenly started getting an error similar to one that came up on |this list last year, but different. | |after running a patch of mine (which makes use of many externals, |including iemlib, ext13 and d_mp3), i close pd (it doesn't seem to matter |how i close it, ctrl-c, file->quit or close-box on the main pd window), |and then future attempts to open pd (any patch / no patch) get the |following error: | |$ pd |rcfile option = -path /usr/local/lib/pd/externs |rcfile option = -path /home/pix/sound/pd/lib |rcfile option = -path /usr/local/lib/iemlib/abs |rcfile option = -lib zexy |rcfile option = -lib iemgui |rcfile option = -lib iemlib1 |rcfile option = -lib ext13 |rcfile option = -lib d_mp3 |rcfile option = -frags 5 |rcfile option = -font 10 |successfully opened /dev/dsp write-only |error: failed to open MIDI ports; continuing without MIDI. |connecting stream socket: Connection refused (111) | |(ignore the midi error, i dont have midi)... | |the similar error last year was about not having the loopback interface |installed, i have this (i know because pd works the first time). so far, |the only way i know to remedy this situation is to reboot. this is pretty |inconvenient as you can imagine... and under linux... rebooting just seems |wrong :) | |there don't seem to be any processes lying around, so i'm wondering what |it is doing to my system?
-- I x Ð v . o 7 g
wait 2 days and do another dist-upgrade or on systems where it works at the mom
this will not do, since i am waiting for 2 and a half week for an upgrade that will let pd run without that error.
one interesting thing (at least to me, because i do not understand it) is, that when you have multiple installations of pd (pe: pd-0.33 and pd-0.32p6) on your system, you can start each of your installations exactly one time, (so you could install 1000 pd's and this would be a real work-around, because few sessions will need to quit and reopen pd a thousand times=
refrain from being on the edge softwarewise. ;)
then why should you run unstable, if you don't want to be the ultrakoolest and softwarewise on the edge.
mfg.dsf.dfs IOhannes
-
_-¯-_ -
CK -
Frank Barknecht -
guenter geiger -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
klaus voltmer -
Miller Puckette -
Nick Fells -
pix -
rat＠telecoma.net