Pd-dev December 2002

pd-dev@lists.iem.at

22 participants
32 discussions

fast hardware access / timimg on Win
by Olaf Matthes 21 Dec '02

21 Dec '02

Hi developers, I'd like to access the parallel port from an external. The problem is the speed: I need more than 1000 (in words: one thousand) accesses per second. I've tried using the IRQ and a callback function but Windows seems to have limitations that result in a maximum callback interval of 1 millisecond. That's still to slow for my purposes. Another idea was to put the hardware acces into the dsp routine and read out the bytes from the parport every - say - 16 samples. But this won't give a periodic access because the execution time of the dsp loop depends on processing time and as long as my external doesn't do any other audio stuff it executes much to fast. Does anybody know how to get access to the IRQs on Win faster than every millisecond? Or is there a way to send a child thread to sleep for a period shorter than 1 millisecond (it appears to me that 1 millisecond is the shortest time interval Win can handle).... ? thanks a lot, Olaf

1 0

Large File Size support
by Miha Tomsic 17 Dec '02

17 Dec '02

Hello! Miller could you add te folowing patch to the makefile.in just to add support for large files (>2GB). I usually add this line by hand, but maybe someone else could make use of the LFS support. Take care, Miha...

1 0

RE: [PD-dev] [GEM] new postrender crashes OS X
by Mark Danks 17 Dec '02

17 Dec '02

Hi all, Couple of observations from afar (yes, I am still here watching how my baby is doing :-) Having dealt with a lot of remote dev, etc before, I would _really_ recommend that you create a stable and experimental CVS branch as Guenter mentions. In past projects I have been involved with, the "active" developers would work on the experminental branch, knowing that at any moment, the entire thing could be broken. "Normal" users or developers would use the stable branch. Every so often, when the experimental branch is good to go, then it replaces the stable branch, and you fork out another experimental one. Also, labeling in CVS is easy and should be used whenever a big checkin happens so people can get back to a known state. On the issue of the processImage stuff, I totally agree that the original design assumptions I made 7 years ago aren't true anymore :-) Remember that all of that code started on an SGI Indy...machines are a bit faster these days. This is one reason why it is such a pain to do streaming pixel manipulation (like on movies). A complete overhaul of the pix system would be a lot of work, but would probably help a lot. I have actually been looking into ways to have objects "advertise" their connection abilities and just let them negotiate the best way to run. This allows for optimized processing for known formats, as well as conversion for formats that the original code hasn't even seen before. BTW, I would recommend that YUV stuff is folded into the normal pix flow. While I know that there are significant differences, etc. between the two formats, it is confusing to end users who don't know the differences. If pixel operations are dealt with differently on Mac vs all the other platforms, then it will be harder to transfer patches and general GEM knowledge for most people independent of the platform. Just my $.02 Later, Mark ============================== = mdanks(a)stormfront.com = Technical Director PS2/XBox = http://www.danks.org/mark ============================== > -----Original Message----- > From: chris clepper [mailto:cclepper@artic.edu] > Sent: Monday, December 16, 2002 5:04 PM > To: guenter geiger > Cc: PD-dev(a)iem.kug.ac.at > Subject: Re: [PD-dev] [GEM] new postrender crashes OS X > > > >A slighlty different proposal. Having taken a closer look at Gem, > >and specifically pix_ processing, I do completely understand that > >Johannes wants to change everything in there. There is no way around > >introducing bugs in this process. > > > >In order to make this transition less painfull, we could > make a stable > >branch of Gem, which will only change for bugfixes, build system > >enhancements etc (no new features !!). > > > >This means of course that there will be no yuv support. > > > >Is there a need for such a branch ? > > Interesting proposition Guenter. Maybe a stable and 'experimental' > branch could help ease transitions in code additions. Another idea > might be to have a 'Core' Gem version that's cross-platform with > extra extensions to accommodate differences and unique features for > each OS. That might alleviate some of our problems. The counterpoint > is that it would mean more work for administrators and potential > confusion for users. Some thing to think about... > > cgc > > >Guenter > > > > -- > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

1 0

Re: [PD-dev] [GEM] new postrender crashes OS X
by bbogart＠ryerson.ca 17 Dec '02

17 Dec '02

Hi James, et all. First off I have to say that James, Adam and Chris, I really appreciate the work you are doing on the OSX port and I think it is of great value to the community. I understand that this development process is difficult, and keeping the cvs working on both sides (linux and osx+others) when all the develppers don't have access to all the OSs is a great challange. I know the last time I tried to use the CVS version on linux, the pix_movie stuff was broken under linux. I don't mean this to be a blame thing, but it is in all our best interests that the changes made are not breaking stuff that had previously worked. I do think a more verbose dialog between developers may help the issues you describe. Any other opinions? B. ----- Original Message ----- From: tigital <tigital(a)mac.com> Date: Monday, December 16, 2002 9:46 am Subject: [PD-dev] [GEM] new postrender crashes OS X > hello, > > ...I'm really not sure what or why IOhannes is doing some of these > changes? So far, they have led to crashes and instability on the > Mac > OS X port. Thanks. I am frustrated, because things that worked > no > longer function correctly! What makes it worse is that these > changes > are done without any announcement or warning, unless you watch the > cvs logs daily...and even then, the logs are not specific to > changes > in a file, and do not give any insight to the scope of the changes... > > ...the first problem came when IOhannes decided to rewrite the > processImage() system: thankfully, he tried to hide most of this > within #ifdef NEW_DUAL_PIX, but there was no discussion as to the > thought behind this... > > ...then he filed a rewrite of rendering: > > deleted pix_fx > the pix_fx functionality is now in GemPixObj > this functionality is: save the image-state before it is processed > and reconstruct it in the postrender function > so we can change size/format and even bend the data-pointer > and objects "before" will not notice (and crash) > > ...this is the cause of my crashes...previously, I could switch > out > movies on the fly when doing dual processing; now we get segfaults > when there is no "old_data"...and this change was supposed to fix > a > crash? haha > > ...I don't see how Mac OS X support for GEM can continue without a > little discussion before unilaterally making changes to cvs that > affect all platforms... > > l8r, > jamie > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

3 2

Re: [Gem] test: pix_yuv
by chris clepper 17 Dec '02

17 Dec '02

At 6:09 PM +0100 12/16/02, IOhannes zmoelnig wrote: >YUV: >again i would like to stress: >please do not make [yuv_*] objects, but make [pix_*] objects with >functions for YUV. The processImage() will then bail out, when >images other than YUV want to be processed. here is my reasoning for making the [yuv_] set objects: - a separate set of objects would be easier to leave out of compiles for platforms that don't support it. i was way over optimistic in my estimation of how well platforms support the yuv color-space. as it stands right now you cannot texture yuv using openGL in windows or linux, and support for this might never even happen on those platforms! i guess we should consider the yuv_stuff mac only for the moment. - there is not a one to one correlation between yuv and rgb color-spaces. in fact they are vastly different, and not compatible in any way. this means that there are certain pix_objects that make no sense for yuv, like anything dealing with the alpha channel. also controls and messages would have to be different for each color-space, for example changing color values in rgb would have 3 controls for red green and blue, but in yuv there are only two chroma channels u and v and the luma changes brightness. that looks like a mess to explain. also conversion between rgb to yuv just to get the same functionality can be slow and lossy if done too much. - Gem already had the pix_ naming convention which made it clear that pix = image processing and that stringing pix_objects together would result in a functional chain. my initial attempts to extend pix to yuv seemed to destroy that, so i decided that yuv_objects would make their own chains to avoid confusion. i also want the name of the object to describe what the object does in fairly exact terms. i get really tired of trying to figure out what the hell an object named after a post-modern theorist or someone's cat is supposed to do. therefore yuv_luma_key does luma keying in the yuv color-space,etc. i really did think about this quite a bit. honestly. cgc >please, mac-people, test, whether the new [pix_yuv] (converter (RGBA) to >YUV) works correctly. >the inverse (YUV2RGBA) is in [pix_rgba] > >btw: i just checked-in some new changes (GemPixObj, GemPixDualObj) which > might crash some compilations (it works at least under linux) >forgive me, but i consider Gem as alpha-software right now i'll check it out, but i'm behind on the cvs updates since i don't have access to the cvs yet. >mfg.asd.f >IOhannes --

1 0

g_canvas.h / C++
by Thomas Grill 15 Dec '02

15 Dec '02

Hi all, it would be great if g_canvas.h would be c++ compilable. The problem is that the reserved c++ word "template" is used as a function parameter a couple of times. Am i allowed to change the cvs version or what is the common procedure of that? greetings, Thomas

2 2

Re: [PD] pix_image threading
by bbogart＠ryerson.ca 15 Dec '02

15 Dec '02

Hello all, I'm finding very little in terms of options for the 500ms delay in rendering when loading an image file. I can't use a movie because my images need to be masked. Can't use pix_multiimage because I'm talking about about 800 images, called up on the fly. So is it possible that the pix_image image loader be put in a seperate thread? (or all the pd/gem disk IO ideally) Is anyone working on an experimental version of this I could use? Or does anyone have any non-thread ideas so solve the render-stop problem? Thanks all. Ben ----- Original Message ----- From: Miller Puckette <mpuckett(a)man104-1.ucsd.edu> Date: Saturday, December 14, 2002 9:27 pm Subject: Re: [PD] soundfiler threading > Hi all, > > The threaded version is readsf~ ... you can use it to gently read a > soundfile into a table using tabwrite~. > > cheers > Miller > > On Sun, Dec 15, 2002 at 09:30:47AM -0600, eskogen(a)usfamily.net wrote: > > hi list, > > > > i'm doing a live set this week and i wish i would have mentioned > this sooner. it's getting to be the one most troubling thing about > using pd live. > > > > i'm running win2k pd .35-1 and i get about a one second delay > every time i use soundfiler to load a sample. i'm using the USB > Quattro with ASIO (to good results) and the latency of everything > else is acceptable. > > > > is there any possibility that soundfiler could be put in a > seperate thread? are there any other options to load in a .wav > file? these files aren't more than 1 or 2 megabytes, i'm suprised > there's such a problem. > > > > the only solution i can think of is to readsf~ the sound into a > table, as that seems to be threaded or something as to keep the > sound from skipping. > > > > ANY help at this late hour would be appreciated! > > > > --eric > > > > > > > > > > > > > > > > > > > > > > ------ http://USFamily.Net/info - Unlimited Internet - From > $8.99/mo! ------ > > > > > > _______________________________________________ > > PD-list mailing list > > PD-list(a)iem.kug.ac.at > > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list > > _______________________________________________ > PD-list mailing list > PD-list(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list >

1 0

Re: [PD-dev] Re: [PD-announce] cyclone-help
by bbogart＠ryerson.ca 13 Dec '02

13 Dec '02

Hey all, Either GPL or the PD license would work me. The Chaos externals are currently under GPL. Any other opinions? Ben ----- Original Message ----- From: guenter geiger <geiger(a)xdv.org> Date: Friday, December 13, 2002 9:36 am Subject: Re: [PD-dev] Re: [PD-announce] cyclone-help > > On Thu, 12 Dec 2002 bbogart(a)ryerson.ca wrote: > > > > I'm trying to find the cylone library and can't > > recall where it is, not in CVS? not in the pure > > database... > > > > (any plans on putting it in cvs? or did I simply > > miss it?) > > No, Krzysztof said he doesn't like the idea of putting cyclone under > GPL. Generally, I think that we can change the license for the > externals,if that is wanted, and put them under the same license as > pd.What do you think ? > > Guenter > > > > > Thanks > > Ben > > > > ----- Original Message ----- > > From: Krzysztof Czaja <czaja(a)chopin.edu.pl> > > Date: Thursday, December 12, 2002 3:21 pm > > Subject: Re: [PD-announce] cyclone-help > > > > > hi Chris, > > > > > > CK wrote: > > > ... > > > > I hope Krzysztof considers merging the docs with > > his release, the > > > > > > will do that in beta testing stage, thanks > > > > > > > (c) is Miller and others > > > > > > great > > > > > > K. > > > > > > > > > _______________________________________________ > > > PD-announce mailing list > > > PD-announce(a)iem.kug.ac.at > > > > > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-announce > > > > > > > > > _______________________________________________ > > PD-dev mailing list > > PD-dev(a)iem.kug.ac.at > > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev > > > >

1 0

cvs wonkiness
by bbogart＠ryerson.ca 13 Dec '02

13 Dec '02

Hey all, I was downloading the CVS external tree today and found something strange, the zexy folder looks a bit weird: There is another zexy folder inside zexy which contains an empty src and examples folders. There is also another externals folder under zexy which contains another zexy which contains another empty src and examples. Looks like a screwed up update, I just thought the developers with stuff in CVS should take a look and make sure everything is in order. Ben

3 3

Re: [PD-announce] cyclone-help
by bbogart＠ryerson.ca 13 Dec '02

13 Dec '02

I'm trying to find the cylone library and can't recall where it is, not in CVS? not in the pure database... (any plans on putting it in cvs? or did I simply miss it?) Thanks Ben ----- Original Message ----- From: Krzysztof Czaja <czaja(a)chopin.edu.pl> Date: Thursday, December 12, 2002 3:21 pm Subject: Re: [PD-announce] cyclone-help > hi Chris, > > CK wrote: > ... > > I hope Krzysztof considers merging the docs with his release, the > > will do that in beta testing stage, thanks > > > (c) is Miller and others > > great > > K. > > > _______________________________________________ > PD-announce mailing list > PD-announce(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-announce >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev December 2002