hey,
i'm just wondering if plugin~ or vst~ will work in OSX. also, is there anything like jack for OSX?
m@. www.ekran.org
i'm just wondering if plugin~ or vst~ will work in OSX.
vst~ doesn't work at this time. But it will (someday).
also, is there anything like jack for OSX?
I've heard, that there's some tool named "daisy" in the Developer-Tools which allows to connect coreaudio channels.
greetings, T
Hallo, Matthew Nish-Lapidus hat gesagt: // Matthew Nish-Lapidus wrote:
i'm just wondering if plugin~ or vst~ will work in OSX. also, is there anything like jack for OSX?
I've read, that someone on linux-audio-user (or -dev?) compiled plugin~ for LADSPA on OS-X, which seems resonable. This gives access to a lot of cool, free, gui-less plugins.
Frank Barknecht _ ______footils.org__
Ivan suggested that this be forwarded to the list as it would help clear up some possible confusion about GEM, OSX, RGB vs YUV, etc:
At 7:00 PM +0000 2/24/03, Ivan Franco wrote:
I'm talking about the basic help files for performance comparison. I'm running a Ti 500 Rev.A (same cheap card as yours :-) ) Yes, I've notice the yuv run much faster, but I was refering to the basic pix_film. I've only noticed there was a yuv movie player a bit after the last mail. Anyways, can it be used together with all the other pix_ processing stuff?? And are all the rest of the yuv objects in the extra help files you provide? Also I noticed there were to yuv players...
Thnx a lot
Ivan
the basic pix_film uses RGB and it has to convert the yuv data in the compressed video file to RGB, which is quite slow. not all of the pix_ objects can do yuv at the moment, so you might have to use some yuv_ objects right now. if you want to use RGB pix_ objects then i recommend using the Animation codec since it's the only codec that uses compressed RGB. this will remove the slow YUV->RGB conversion. incidentally that conversion was done in hardware by quicktime/quickdraw until recently (QT6 changed it?). i'm trying to figure out how to get it back in OSX. in general the OSX version is really designed to use YUV the whole way, in fact it's the only platform that can do it at the moment.
there are two yuv players (yuv_film and pix_filmYUV) that are identical. since all of the yuv_ objects are in the process of being rolled into the pix_ ones there is the pix_fillmYUV as a transition object. at some point there will probably just be pix_film that does both RGB and YUV based on a message or argument, but right now that doesn't work because openGL doesn't like switching color-spaces on the fly.
docs and a tutorial are really lacking at this point so you'll have to bear with it for the time being. on the other hand if you are a fantastic doc writer maybe you can help out...
cgc
the last part about 'fantastic doc writer' is open to anyone. i personally would prefer a non-developer to write the tutorial because the people writing the code are generally pretty bad about writing 'howto' information. also, some distance from the project might make the whole thing more objective.
I know that the vst~external is no longer supported, and in fact, i couldn't find it the net. But i want to toy with this.
So, can anyone please e-mail me this external along with a pd help-patch that explains how to use it? I have pd running in windows, so i guess i need the vst.dll or something similar.
Thanks in advance.
Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
one more quick note to anyone using the GemG4 build:
make sure that the .mov sizes are 16byte multiples (128bit) or you will risk a crash. all of the common video sizes, both NTSC and PAL, are compliant (320x240, 720x576, 640x480, etc) so if you are using these don't worry. however, if you have some need to use a 211x317 or any other odd sized file you might run into this problem. additionally, the standard sized movies should also be 64byte aligned making for much better cache transfers, which just makes the whole process faster. if you have no idea what the hell i'm talking about then just stick with a standard NTSC or PAL sizes and everything will be fine.
this will all go into a README on the webpage before the end of the day.
cgc
Hello cgc, list: when loading films I constantly get: error: GEM: yuv_film: track 0 number too high (max -1) meaning...?
Ivan
On Tuesday, February 25, 2003, at 08:37 PM, chris clepper wrote:
one more quick note to anyone using the GemG4 build:
make sure that the .mov sizes are 16byte multiples (128bit) or you will risk a crash. all of the common video sizes, both NTSC and PAL, are compliant (320x240, 720x576, 640x480, etc) so if you are using these don't worry. however, if you have some need to use a 211x317 or any other odd sized file you might run into this problem. additionally, the standard sized movies should also be 64byte aligned making for much better cache transfers, which just makes the whole process faster. if you have no idea what the hell i'm talking about then just stick with a standard NTSC or PAL sizes and everything will be fine.
this will all go into a README on the webpage before the end of the day.
cgc
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list