Le Mon, 07 May 2001, Mark Danks a écrit :
The Voodoo2 only accepts 256x256 or smaller...if you try to display anything larger, it will just reject the texture and make the polygon white. pix_movie does not try to resize the texture or anything else. Also, pix_movie immediately uploads the texture, so if it isn't a power of two, you will not have any texturing.
My intent was at first to display movie as they are, without 3D positionning or mapping to geos.
With pix_draw I can display pictures larger than the texture ram because it is directly rendered without passing through it.
I was hoping that since I can do it with picture (and even not power of 2, btw it works despite an error message), i could display movies with larger res.
It would be too slow not using texture ram for displaying simple movie on the "flat screen" ?
BTW, is it possible not to resize but to cut in a source movie a square of the wanted size to then pass it to the texture object ?
Linium (who have to consider a new 3D card)
Hello everybody,
I would like to know if someone using pd and Gem rtx under windows 98 ?
Which hardware needded ?
Best salutations
J ! J !
I would like to know if someone using pd and Gem rtx under windows 98 ?
Which hardware needded ?
i tried it under w98 with a hauppauge wintv card (bt878 chip) and it worked very good! (p2/400/384mbram/ati rage pro card with 8mb)
regards,
ulrich
Best salutations
J ! J !
On Tue, 8 May 2001, Linium wrote:
My intent was at first to display movie as they are, without 3D positionning or mapping to geos.
i have written a very ugly piece of code for this purpose.
i have modified the pdreceive program - it
stores a sequence of tga files in memory and displays
one of them dependig from udp messages it gets from pd.
as ugly as it was, it worked quite well on my venerable p200 labtop.
if someone wants to improve it i'd be happy to give it away (the
code, not the labtop).
maybe it would be interesting to patch a movie player (like xanim) with netreceive ...
norbert
I read:
i have written a very ugly piece of code for this purpose. i have modified the pdreceive program - it
stores a sequence of tga files in memory and displays one of them dependig from udp messages it gets from pd. as ugly as it was, it worked quite well on my venerable p200 labtop. if someone wants to improve it i'd be happy to give it away (the
well pls tell us the URL though I doubt that I'll vastly improve it, I'd definitely like to take a look at it.
code, not the labtop).
damnit!
lg
x
Dear list.
I'm running PD31 on Win98 (PIII 650 - 128mo Ram). Of course I envoy it ;-)
I'm creating rythms with PD : I use in the same time midi in to receive parameters and midi out to send note coresponding to the rythme... Many fun...
It's only midi processing so i turn audio calculation off.
My problem apear when i have an heavy load on midi : the rythme became not regular !!!
What can help me ?
- win NT instead of 98 ?
- linux ?
- PD32.6 instead of PD31 ?
- change the soundcard (SB live today)
- change the block size and overlap (I guess that midi is related to the
block size) 6) change the PC ? 7) other idea ???
thanks.
dh.
Hi dh,
I've never measured MIDI timing stability in W98, but in general Pd doesn't time MIDI I/O carefully in either NT or Linux; output gets sent at the time teh audio is COMPUTED, not when the audio actually appears on the output. To reduce MIDI jitter, you can reduce audio latency to the lowest amount Pd can stand. I think you should be able to get jitter down to 5-10 msec this way in W988 (it will be worse than this, probably, in NT or W2000).
cheers Miller
On Tue, May 08, 2001 at 11:07:04PM +0200, HENRY Damien wrote:
Dear list.
I'm running PD31 on Win98 (PIII 650 - 128mo Ram). Of course I envoy it ;-)
I'm creating rythms with PD : I use in the same time midi in to receive parameters and midi out to send note coresponding to the rythme... Many fun...
It's only midi processing so i turn audio calculation off.
My problem apear when i have an heavy load on midi : the rythme became not regular !!!
What can help me ?
- win NT instead of 98 ?
- linux ?
- PD32.6 instead of PD31 ?
- change the soundcard (SB live today)
- change the block size and overlap (I guess that midi is related to the
block size) 6) change the PC ? 7) other idea ???
thanks.
dh.
Hi Miller, Hi list.
When I send many midi event with noteon spaced like this :
! ! ! ! ! ! ! ! ! !
I get something like this :
! ! ! ! ! ! ! ! ! !
it's not a ramdom jiter, it's like an interference phenomena. Like if the regular rythme was modulated by an other. I've tried to generate an audio sound based on the same rythme, and this one is very regular : the jiter apear only on the midi output. I've play with -audiobuf without any good results... With 5ms, the midi rythme is 2 time slower than with 500ms or without using the -audiobuf flag. (I don't understand why)
- If too many event arrive in the same time to a noteon object, does PD
"decide" to schedule some for later ?
2 )Are MAXBUFFER and DEFBUFFER in the s_nt.c code file linked to midi timming ? Do you think that playing with this king of buffer can solve my problem ?
Thanks for your answer and help.
dh.
Hi dh,
I've never measured MIDI timing stability in W98, but in general Pd
doesn't
time MIDI I/O carefully in either NT or Linux; output gets sent at the
time
teh audio is COMPUTED, not when the audio actually appears on the output. To reduce MIDI jitter, you can reduce audio latency to the lowest amount Pd can stand. I think you should be able to get jitter down to 5-10 msec this way in W988 (it will be worse than this, probably, in NT or W2000).
cheers Miller
On Tue, May 08, 2001 at 11:07:04PM +0200, HENRY Damien wrote:
Dear list.
I'm running PD31 on Win98 (PIII 650 - 128mo Ram). Of course I envoy it
;-)
I'm creating rythms with PD : I use in the same time midi in to receive parameters and midi out to send note coresponding to the rythme... Many fun...
It's only midi processing so i turn audio calculation off.
My problem apear when i have an heavy load on midi : the rythme became
not
regular !!!
What can help me ?
- win NT instead of 98 ?
- linux ?
- PD32.6 instead of PD31 ?
- change the soundcard (SB live today)
- change the block size and overlap (I guess that midi is related to
the
block size) 6) change the PC ? 7) other idea ???
thanks.
dh.
Hmm,
I don't know the answers to any of this, except that, for the second question, notein just asks the OS to get the MIDI out as fast as possible. I'm surprised setting a small audiobuffer doesn't help. Another possibility is turning audio input or output (or both) off. MIDI is timed off audio transfers, so if teh OS is using a large block size for audio, MITI timing should suffer.
I'm going to work on this and see if I can improve it at all; I can probably get the timing jitter down to 5msec or so but it'll never be real pro quality until someone figures out how to use kernel-level time tagging on MIDI output...
cheers Miller
On Sun, May 13, 2001 at 10:12:58PM +0200, HENRY Damien wrote:
Hi Miller, Hi list.
When I send many midi event with noteon spaced like this :
! ! ! ! ! ! ! ! ! !
I get something like this :
! ! ! ! ! ! ! ! ! !
it's not a ramdom jiter, it's like an interference phenomena. Like if the regular rythme was modulated by an other. I've tried to generate an audio sound based on the same rythme, and this one is very regular : the jiter apear only on the midi output. I've play with -audiobuf without any good results... With 5ms, the midi rythme is 2 time slower than with 500ms or without using the -audiobuf flag. (I don't understand why)
- If too many event arrive in the same time to a noteon object, does PD
"decide" to schedule some for later ?
2 )Are MAXBUFFER and DEFBUFFER in the s_nt.c code file linked to midi timming ? Do you think that playing with this king of buffer can solve my problem ?
Thanks for your answer and help.
dh.
On Sun, 13 May 2001, Miller Puckette wrote:
[...] I can probably get the timing jitter down to 5msec or so but it'll never be real pro quality until someone figures out how to use kernel-level time tagging on MIDI output...
Does that mean you need tagged messages from the kernel level drivers, or that you can get tagged messages but you don't know how to use the tags in relation to the rest of Pd?
I know there is MidiShare, which works on all the Pd platorms, and does tagging...
(jfm3)
On Tue, 15 May 2001, jfm3 wrote:
On Sun, 13 May 2001, Miller Puckette wrote:
[...] I can probably get the timing jitter down to 5msec or so but it'll never be real pro quality until someone figures out how to use kernel-level time tagging on MIDI output...
Does that mean you need tagged messages from the kernel level drivers, or that you can get tagged messages but you don't know how to use the tags in relation to the rest of Pd?
I know there is MidiShare, which works on all the Pd platorms, and does tagging...
This comment was related to output not input - I think what Miller is referring to is using the OSS sequencer to schedule midi events. I guess the idea is to schedule events in the future with the sequencer - this would reduce jitter but increase latency. Also, wouldn't event granularity still be limited by at least DACBLKSIZE (somewhere around 3msec)?
Karl
(jfm3)
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | mambo.peabody.jhu.edu/~karlmac |
Well, actually I'm going to try to improve both input and output jitter by making my own time-tagging mechanism, both for input and output, in user space. That way it will work on all the platforms the same way...
cheers Miller
On Tue, May 15, 2001 at 06:02:29PM -0400, Karl MacMillan wrote:
On Tue, 15 May 2001, jfm3 wrote:
On Sun, 13 May 2001, Miller Puckette wrote:
[...] I can probably get the timing jitter down to 5msec or so but it'll never be real pro quality until someone figures out how to use kernel-level time tagging on MIDI output...
Does that mean you need tagged messages from the kernel level drivers, or that you can get tagged messages but you don't know how to use the tags in relation to the rest of Pd?
I know there is MidiShare, which works on all the Pd platorms, and does tagging...
This comment was related to output not input - I think what Miller is referring to is using the OSS sequencer to schedule midi events. I guess the idea is to schedule events in the future with the sequencer - this would reduce jitter but increase latency. Also, wouldn't event granularity still be limited by at least DACBLKSIZE (somewhere around 3msec)?
Karl
(jfm3)
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | mambo.peabody.jhu.edu/~karlmac |
Hi Miller.
You where right : using the -nosound flag increase the stability of MIDI timing : it run perfectly now even with a *very* high load of the midi output. I understand only now that the calculate audio checkbox is diferent than the -nosound flag.
For info : I've use the same patch on Win98 and Linux and the MIDI timming is better with Linux when the -nosound flag is *not* activated. when it is activated they are both good.
I will use 2 PD in the same time one with -nosound and one other with -nomidi. It will solve my problem.
many thanks.
dh.
De : Miller Puckette mpuckett@man104-1.ucsd.edu Envoyé : lundi 14 mai 2001 00:17 Objet : Re: [PD] midi syncro
Hmm,
I don't know the answers to any of this, except that, for the second question, notein just asks the OS to get the MIDI out as fast as possible. I'm surprised setting a small audiobuffer doesn't help. Another
possibility
is turning audio input or output (or both) off. MIDI is timed off audio transfers, so if teh OS is using a large block size for audio, MITI timing should suffer.
I'm going to work on this and see if I can improve it at all; I can
probably
get the timing jitter down to 5msec or so but it'll never be real pro quality until someone figures out how to use kernel-level time tagging on MIDI output...
cheers Miller
On Sun, May 13, 2001 at 10:12:58PM +0200, HENRY Damien wrote:
Hi Miller, Hi list.
When I send many midi event with noteon spaced like this :
! ! ! ! ! ! ! !
!
!
I get something like this :
! ! ! ! ! ! ! !
!
!
it's not a ramdom jiter, it's like an interference phenomena. Like if the regular rythme was modulated by an other. I've tried to generate an audio sound based on the same rythme, and this
one
is very regular : the jiter apear only on the midi output. I've play with -audiobuf without any good results... With 5ms, the midi rythme is 2 time slower than with 500ms or without using the -audiobuf
flag.
(I don't understand why)
- If too many event arrive in the same time to a noteon object, does PD
"decide" to schedule some for later ?
2 )Are MAXBUFFER and DEFBUFFER in the s_nt.c code file linked to midi timming ? Do you think that playing with this king of buffer can solve my problem
?
Thanks for your answer and help.
dh.
-
CK -
HENRY Damien -
J ! J ! -
jfm3 -
Karl MacMillan -
Linium -
Miller Puckette -
Norbert Math -
Ulrich Kehrer