Pd-list August 2005

pd-list@lists.iem.at

138 participants
217 discussions

EOF on socket
by nico 18 Aug '05

18 Aug '05

hi all can anybody explain me [netreceive] message i send to [netreceive] message like 1 33, 2 77, 3 23, .........,15 89, ; every 100 ms in the console i get EOF on socket 22 EOF on socket 22 EOF on socket 22 EOF on socket 22 and sometimes EOF on socket 23 EOF on socket 24 EOF on socket 22 and this is not good any idea? best regards

4 11

pd alsa midi
by derek holzer 18 Aug '05

18 Aug '05

Which "stable" versions of PD contain the ALSA-MIDI patch? thx. d -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 169: "Use filters"

1 0

gem compile problem
by we are 18 Aug '05

18 Aug '05

trying to compile gem on a debian system with ./configure scipt coming up with this... checking for XF86VidModeGetAllModeLines in -lXxf86vm... (cached) no and when i make it dies with a related error. clues? thanks

2 1

OT (haha!) Media/Electronic Arts in Hamburg...
by B. Bogart 17 Aug '05

17 Aug '05

Hi all, I'm going to be in Hamburg from Sept 1st to 15th. Hoping to drive out to Amersterdam as well, but we'll see about the car thing... So I thought I would ask you good bunch of people whats happening in Hamburg in media arts, art centres, galleries, organizations, clubs and people... Drop me a line. Of course I really hope to be at piksel in Bergen this October, so I know I'll meet a lot of you there. B.

1 0

[Fwd: Re: [PD] hardware recommendation]
by Matthijs van Henten 17 Aug '05

17 Aug '05

sorry iohannes, I always forget to reply to the list. - this could be set somewhere in the mailman software, because it doesn't happen in every mailinlist I post to, in the mailto thingy. from what I understand now is that power needs to be in the GPU - and agreed, any fairly recent graphics card will do I think. I can't compare ATI to NVIDIA since I only have ATI, but mine was 55 euro and I think would do the job. You can use medium processors too, and don't need anything specific on storage side - I'd go for 2 pc's in that case, cince your hw doesn't have to be the top of the line in CPU power or features. Matrox cards are not an option for anything 3d. Only Parhelia ( 4 head card) would be interesting, but that's almost the price of 2 pc's IOhannes m zmoelnig wrote: > Georg Holzmann wrote: > >>Hallo! >> >> >>thanks - the problem is only, that I think this card will be a little >>bit too expensiv (would need 2 of them ...) > > > almost all (? probably all) "modern" nvidia cards (>= fx) will have 2 > VGA-outputs, and they cost very little. (~70Â€, guess you can get one for > 50 too) > > > cyrille henry schrieb: > >>>I don't think you'll be able to have DRI on a window crossing 2 >>>craphic card. >> >>:( >> >>tati schrieb: >> >>>if you use them with xinerama you can't have dri, but at least with >> >>do you mean it's even not possible on "only" 2 screens ? > > > just use nvidia's "TwinView" to drive a xinerama-like dual-head screen > with hw-acceleration on both. > > >>Question regarding the grafic card: >>of course ati radeon and nvidia seem to be the best solution - but >>expensive >>has anyone experience with e.g. Matrox G450 Dualhead (they seem to have >>good linux support) - dri on both screens ? > > > even if matrox has "dri" support, this is (to my experience) nothing you > can compare with nvidia's (and probably radeon's) acceleration. > > with _wild_ numbers i'd say: > software-GL: 1x > matrox-DRI : 3x > nvidia-GL : 50x (well, probably 10x or 20x) > > > >>1 vs. 2 computer: >>so I think it won't be possible with 1 computer and 4 screens ? >> > > > well, there are mainboards with 2 AGP-slots (are there ?) > or you can use 1 AGP and 1 PCI card (like chris has mentioned, PCI is > not that fast with texture uploading) > i think you would have to use 2 X-servers on your machine and then run 2 > instances of pd/gem > > > mfg.adr. > IOhannes > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >

2 1

hardware recommendation
by Georg Holzmann 17 Aug '05

17 Aug '05

Hallo list! I have to use 4 800x600 projectors with 4 channel sound for an installation, so I wanted to ask if someone can share some experiences which hardware we should buy ... the organizers suggested the following: athlon64, 1.8ghz 1gb ram 2x matrox g200 dualhead pci. (1 or 2 computers) 1) Should I really try to use the 64 bit processors :) (on linux of course) ? 2) I think I will use GEM (it's not much to do - I have to display some images and text ...), so I am just thinking about, how to use 4 projectors: - I could use 2 computer with a dualhead graphic card, then make a big GEM window over all 2 heads - 1 computer with 2 dualhead graphic cards and make a big GEM window over all 4 heads ? - or maybe start 2 PDs on one computer to have 2 gemwins (trying to avoid the experimtental multiple gemwin feature ...) 3) matrox g200: has anyone experiences with that card - I searched google and found an (old) article, there it was said, that it's not possible to use DRI with 2 screens on linux ... or could someone suggest an other card? Thanks a lot for any suggestion, LG Georg -- =%)!:?"§<§0ß-"|>* http://grh.mur.at

7 8

... and another pool question
by Thoralf Schulze 17 Aug '05

17 Aug '05

hi again, while we're at it: I noticed in the xml files that the first key stores the name of the folder whose data were saved ... Does that mean that these data can only be loaded into a folder of the same name? Or does that key just has an informational value? Thanks again, Thoralf. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

1 0

pool problem - can't load data into dirs
by Thoralf Schulze 17 Aug '05

17 Aug '05

Hi all, hi Thomas - I can't get pool to load data into subdirs ... I thought it should work this way: 1. mkdir dirname 2. chdir dirname 3. set some data 4. svdir / svxdir those data everything fine so far ... 5. clrall data in this dir - works, too 6. lddir / ldxdir data 7. getall: ooops. no data, instead error messages: "pool - output atom: type not supported!" I'm pretty sure I'm overlooking the obvious ... thank you for your help, thoralf. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

1 0

Re: [piksel] Re: [PD] Piksel'05
by james tittle 17 Aug '05

17 Aug '05

On Aug 17, 2005, at 5:28 AM, Gisle Fr0ysland wrote: > Tuesday 16 August 2005 20:20, skrev B. Bogart: > >> The bottom line is that everything in pixelTANGO is free and >> multi-platform BUT those non-free components that get linked with >> Gem on >> OSX make it perform much better for certain operations. We just need >> ffmpeg (or something) function as well as quicktime and decoders that >> are very fast and optimized... >> >> Say anyone know of anyone using the GPU to do some decoding work with >> pixelShaders? >> > > hi ben, > > you're touching some very important issues here, and in fact one of > the main > reasons why we initiated Piksel in the first place. > > I have often been surprised by linux developers' seemingly lack of > interest > for anything that goes on outside their own application. The > general attituse > seems to be that 'the other stuff is not my responsibility, so I > just have to > blindly rely on what other coders are doing'. This is specially > true for > video apps where everybody seems to be closing their eyes for > things like the > lack of a unified high-quality playback-engine and free hq codecs. ...even as an avid user of quicktime I will readily admit that it does some stupid things (like always transparently resizing/rescaling dv, even if it's just to a scale of 1?!?)...so I've often wondered where the "good" codecs are for video art use? It seems to me we need a "vj codec", something like a modern, highquality, fullframe photo-jpeg that is highly optimized and low in cpu usage, but most work seems to be going into streaming architecture codecs...this is certainly great for delivery, but it doesn't seem to be the best (yet?) for screwing around in realtime...anyway, it's unfortunately one project too far for me to jump into atm... > We should learn from the linux audio community and their effort to > advocate > the low-latency patches which is finally in the latest kernels. > We not only need a video-jack but also a video-alsa! ...pdp and gem have some nice interworking objects so that video from one can go to the other, and these will just get better...and there are "video-jack"-type efforts, I just don't think they've gotten much momentum behind them (so little momentum that I can't recall the name of the one I'm thinking about)... l8r, jamie

1 0

Re: [piksel] Re: [PD] Piksel'05
by Christian Klippel 17 Aug '05

17 Aug '05

hello all, Am Mittwoch 17 August 2005 11:28 schrieb Gisle Fr0ysland: [...snip...] > > I have often been surprised by linux developers' seemingly lack of interest > for anything that goes on outside their own application. The general > attituse seems to be that 'the other stuff is not my responsibility, so I > just have to blindly rely on what other coders are doing'. This is > specially true for video apps where everybody seems to be closing their > eyes for things like the lack of a unified high-quality playback-engine and > free hq codecs. > some words about optimized code..... a long time ago i was coding the vdsp stuff for jmax, vdsp was meant as a video extension for jmax. to get the best performance, i banged my head into mmx coding, with good results. but, coding in mmx (or sse, sse2... i can only speak for the intel-compatible world here, and when i say mmx, i also mean the sse/etc...) requires some carefull thought, and some knowledge how those commands are processed inside the cpu. i think that many people just dont want to go through that effort, or they simply dont see that this effort is _really_ needed to produce some mmx code that is faster than native c. you can _not_ just use some mmx and think it will give you a boost. if you dont take care about the execution pipelines, word alignment, etc, it may even happen that the mmx code is actually not faster, or even slower than the c counterpart. this has to do with the way those instructions are scheduled. for example, in mmx the instructions are pipelined. but not every instruction can be executed in any pipeline. some instructions can bes executed in both, some only in a specific pipeline. now, if you dont care about the instruction sequence in mmx code, it can happen that the pipeline is blocked, so that the next instruction has to wait. if that happens, also the cache is flushed, etc. the result is that there will be many cycles lost for that, plus the new fetching of instructions, cache fill, etc. taking care of that is known as instruction-pairing. unless there is taken care of those facts, using mmx instructions will not give you much gain. i guess that some of those constraints also apply to altivec, but im not sure. for the interrested, here you can find the mmx code i had written for some image operations: http://mamalala.de/mmx_ops.tgz they are really fast, feel free to use them wherever they make sense. some good reads about mmx and optimizations: http://www.hayestechnologies.com/en/techsimd.htm#SSE2 http://www.gamedev.net/reference/articles/article1987.asp http://casl.csa.iisc.ernet.in/ComputerArchitecture/pentopt.html (there was also another site, but i lost the link ... some mr. tomasi, with pixel32 or the like ....) after i have finished my current hardware stuff, i would be happy to help people out with optimizing some code. or at least give some hints and tips. > We should learn from the linux audio community and their effort to advocate > the low-latency patches which is finally in the latest kernels. > We not only need a video-jack but also a video-alsa! > yes ! > cheers > -gisle > greetings, chris > ps - I hope we can continue these discussions during piksel05 and follow up > on the efforts contained in the piksel video framework.

2 1

← Newer
1
...
10
11
12
13
14
15
16
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list August 2005