Pd-list December 2007

pd-list@lists.iem.at

129 participants
239 discussions

gem, shader and framebuffer
by cyrille henry 08 Dec '07

08 Dec '07

hello, In the recent discution on this list regarding gem an shader, i read that shader could not be used with framebuffer. i did not realize when i read this (and i can't find it anymore on the archieve). in fact it is not true. shader has to be loaded before the framebuffer objet but it work. here is an exemple of how to use a shader and render on the framebuffer and then using the framebuffer as a texture send to an other shader. hope that help Cyrille

3 9

[Fwd: Re: gem, shader and framebuffer]
by cyrille henry 08 Dec '07

08 Dec '07

-------- Message original -------- Sujet: Re: [PD] gem, shader and framebuffer Date: Sat, 08 Dec 2007 19:56:45 +0100 De: cyrille henry <cyrille.henry(a)la-kitchen.fr> Pour: vade <doktorp(a)mac.com> RÃ©fÃ©rences: <475AAF49.5000301(a)la-kitchen.fr> <4EB30B63-C533-49C1-9812-F5F6F12873B7(a)mac.com> <B5D2002C-0EAF-46F0-9AFF-439213FD5B24(a)mac.com> vade a Ã©crit : > Ok, I stand by my earlier statement., The pd shader patch which leads > to the gemframebuffer is, as far as I can tell, non functional - > only if I disconnect it can I see any texture on the sphere at all. I > do get output however of the sphere, but the only fractal . > Interesting., > > What does your output look like? the fractal on the sphere is distorded with noise. in fact, this patch use 2 time the same shader. >- Its hard to know if its working, im > getting no errors in the PD console. Thanks again, this is exciting > stuff. it look like not working. try marius patch... cyrille > > > On Dec 8, 2007, at 12:51 PM, vade wrote: > >> Alas, - it works, but I misunderstood the patch. Im going to give a go >> at making some stream processing happen. >> >> Thanks! >> >> >> On Dec 8, 2007, at 9:50 AM, cyrille henry wrote: >> >>> hello, >>> In the recent discution on this list regarding gem an shader, i read >>> that shader could not be used with framebuffer. >>> i did not realize when i read this (and i can't find it anymore on >>> the archieve). in fact it is not true. >>> shader has to be loaded before the framebuffer objet but it work. >>> >>> here is an exemple of how to use a shader and render on the >>> framebuffer and then using the framebuffer as a texture send to an >>> other shader. >>> >>> hope that help >>> >>> Cyrille >>> >>> >>> < >>> shader_and_framebuffer >>> .zip>_______________________________________________ >>> PD-list(a)iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> >> _______________________________________________ >> PD-list(a)iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > >

1 0

drop out free audio on windows
by Roman Haefeli 08 Dec '07

08 Dec '07

hi all every now and then i hear people complaining here in the list or on #dataflow in irc, that audio is affected (drop outs), when doing some gui stuff in pd on windows. i don't know about osx, but on linux, i never experienced, that the gui was the cause for drop-outs, even if it consumes a lot of cpu power. i assume, this is because the gui-process and the dsp engine are started with different priorities on linux. today i wanted to test one of my patches on windows. it is part of the patch, that a visible array is updated every 100ms. indeed, i got a drop-out on every update, so that my patch sounded like an uzi. turning the array update off removed also the drop-outs. i found out, that 'pd.com' and 'wish84.exe' were running with the same priority, so i set 'pd.com' in the windows task manager to 'realtime priority'. as usual, windows pops-up a message saying that this is dangerous and might harm the system. however, after that i could turn on the array update without getting drop-outs anymore. i just wanted all the windows user to let know, that there _is_ a way to optimize your pd. probably someone with a deeper knowledge about windows than me knows a way, how to set priorities permanently, so that it doesn't need to be changed in taskmanager after each launch of pd (?). i tested with: windows xp home pd vanilla 0.40.2 roman ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

3 2

Re: [PD] so, what about that deal in brazil for the next pdcon again?
by PORRES 08 Dec '07

08 Dec '07

No, nobody asked me that yet, but I will have some news that can be related to that shortly... please, again, if you wanna talk to me about this stuff, do send the emails concerning this directly to my email ( mentalosmosis(a)yahoo.com ). Best, Alexandre Torres Porres --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search.

1 0

avoiding distirtion
by maciej wojnicki 08 Dec '07

08 Dec '07

hi list i use pd to perform live with few patches some to loop live vocals some for synth and some for samples every patch has its own dac~ output and quite often i use more than one [*~] objects on the way put more than one track the signal line so in the end it is quite hard to keep the sound level low enough to avoid distirtion are there any good strategies to maintain pd output when using many patches at the same time? shall i use any mixers, limiters, compressors, gates etc.... or is there no other way than cleaning the mess and being very carefull with the volume the point with playing live is a well known fact that when there is more than few tracks if something is to quiet i turn it up then something else is to quiet so i turn it up then something else.....and so on that i get an uncomfortable fuzz in the end i miss some master volume slider greets maciek --------------------------------- Never miss a thing. Make Yahoo your homepage.

2 1

segmented patchcords (was Re: PD & MAX)
by marius schebella 08 Dec '07

08 Dec '07

segmented patchcords can make patches less readable, but most of the time they make patches more readable, and that is when you use so many unsegmented cords that they hide the objects. also when you want to connect an object at the bottom of the patch to an object at the top, then you can lay the cord at the outside of the patch to make the ~feed-back. you don't want patchcords in situations where it is not clear anymore which cord is going where. a big problem in max is that there is no undo for segmented patchcords. once segmented, you can only delete them and redraw to make them not segmented. that might be one of the new features of max 5... as well as the infinite number of undos. (true?) marius.

23 62

[Fwd: Re: Music made with Pd]
by star morin 08 Dec '07

08 Dec '07

-------- Forwarded Message -------- From: star morin <shift8(a)digitrash.com> To: Kyle Klipowicz <kyleklip(a)gmail.com> Subject: Re: [PD] Music made with Pd Date: Fri, 07 Dec 2007 19:21:17 -0800 thanks, kyle. vocoder_voice.pd (misnamed :) is really just a small number of changes made to 3.phase.vocoder.pd to make it able to be part of an abstraction with the addition of a slicer that i made (inspired from improbable orchestra, josh steiner et al) and then converted to use millisecond start/end/duration values instead of sample number for offsets. all my stuff is pretty hacky so don't judge too harshy :) and thanks for pointing out that i didn't include panner_gop~ and drum-delay-small :) forgot they weren't sub patches. i've reattached all 4 objects. hit the red button to load samples (preferably ones made as repeatable loops as they work best!) on each instance, then check the first checkbox in the [note_gen] to start playing random slices, and the second one (with the first still checked) to use a randomly generated sequence (32) to play. hit the left-most bnag button to generate a new sequence to drive the payback. On Fri, 2007-12-07 at 19:01 -0600, Kyle Klipowicz wrote: > This tool is great! I think that a vocoder_voice-help.pd file would be > awesome. Also it might help people's understandings of the tool if you > add labels to the gui objects. > > ~Kyle > > On Dec 5, 2007 3:14 PM, star morin <shift8(a)digitrash.com> wrote: > > cool! i really enjoyed the headphone festival - i participated this > > year as well in the san francisco session as "lna" (aka low noise > > amplifire) > > > > i performed using only a patch i made in pd and a home-brew 24 element > > OSC controller. pd patch is 4 instances of one abstraction - a > > sample-slicer/ playback deally w/ random segment playback, random > > segment seq gen. it uses a slight adaption i made of 3.phase.vocoder.pd > > for sample playback and manipulation. > > > > i made it mostly during last minute patching sessions in the days b4 > > (and of :) the show, so it's a bit messy and undocumented. i've > > attached it to this mail if you want to check it out. load up some > > samples, increase the volume. play around w/ controls :) if you dig > > around a little it's not to hard to trace out what the gui elements do. > > > > still waiting on the the official archive, as i didn't record my set > > myself. you can check out an example of a track/performance i created > > live with it here though: > > > > https://admin.vocoid.com/files/active/0/bloerp-retouched.mp3 > > > > all samples are snippets of compositions of mine from over the years and > > some nice archive.org bits. > > > > regards, > > -shift8 > > > > > > On Tue, 2007-12-04 at 22:42 -0500, Hans-Christoph Steiner wrote: > > > Some nice textures there, did you post the patches anywhere? > > > > > > .hc > > > > > > On Dec 1, 2007, at 12:34 PM, Marko Timlin wrote: > > > > > > > To whom it may concern... > > > > January 2007 I played a solo concert at the "le placard headphone > > > > festival" in Helsinki. The music was entirely improvised using pure > > > > data. > > > > The audience in the concert space could only listened to the > > > > concert via headphones - which was a very extraordinary experience > > > > I have to admit. > > > > If you are interested, you are cordially welcome to listen to the > > > > two tracks that are now in the net. You can find them under: > > > > http://www.timlin.de/music.html > > > > > > > > Best, > > > > Marko > > > > > > > > _______________________________________________ > > > > PD-list(a)iem.at mailing list > > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > > > > listinfo/pd-list > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > ---- > > > > > > All mankind is of one author, and is one volume; when one man dies, > > > one chapter is not torn out of the book, but translated into a better > > > language; and every chapter must be so translated.... -John Donne > > > > > > > > > > > > _______________________________________________ > > > PD-list(a)iem.at mailing list > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > -- > > Mechanize something idiosyncratic. > > ---------------------------------- > > cell : 415.828.1625 > > yahoo : the_shift8 > > aim : og_shift8 > > > > > > _______________________________________________ > > PD-list(a)iem.at mailing list > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > > > -- Mechanize something idiosyncratic. ---------------------------------- cell : 415.828.1625 yahoo : the_shift8 aim : og_shift8

1 0

Re: [PD] [psql] object hand-holding
by Hans-Christoph Steiner 08 Dec '07

08 Dec '07

On Dec 7, 2007, at 8:24 PM, Mike McGonagle wrote: > > > On Dec 7, 2007 6:44 PM, Hans-Christoph Steiner <hans(a)eds.org> wrote: > > Since both the current Pd-SQL devs (Mike and Jamie :) have posted > to this thread, I want to bring up the interface again. What do > you guys think about the two inlet interface for SQL objects? I > just find the sql/sqlend thing very strange, and it could end up > being difficult to work with. I see the interface like this: the > hot inlet is for meta commands, like "open", "close", "export", > "connect", etc. Then the second, cold inlet is for building SQL > queries. Having a cold inlet devoted to building SQL queries would > mean that you would not need any special "sql/sqlend" style tags at > all. > > Hans, I still think you are missing the point. The end tag 'endsql' > and 'submitsql' are needed so that we can reinsert the commas that > PD strips out of the messages. Without having the end tag, there > would be no way to tell exactly where the SQL statement ends. > > And as far as it being difficult to work with, I just think of the > closing tag as being a replacement for a semi-colon in the SQL. > Pretty much everything else between the two tags is assumed to be > PURE SQL, and gets placed into the SQL buffer. As PD splits up the > messages based on where the comma's fall, we are assuming that each > time the 'anything' method gets called, that we have to reinsert > the comma into the SQL. The doesn't happen with the first 'sql' tag. > > As far as the second inlet, I can see doing that, but only for the > reason that this 'syntax' is a little different than what PD > normally expects. Other than that, I really don't see any reason to > have a second inlet. > > > Instead, you'd just send messages to the cold inlet, those messages > would be appended to the existing SQL message buffer. Then when > the query is ready to be sent, send a "submit" or "run" or whatever > to the hot inlet, and it would run the buffer from the cold inlet > and clear it. There would also be a "clear" command to just clear > the buffer without sending it. > > So, then, how would we allow the ability to insert multiple SQL > statements into a single buffer? The point of having the sql/endsql > tag pairs is to delimit a single statement. I don't think that > Jamie's external will allow multiple statements, I could be wrong, > but I think it would be very desirable to have the ability to build > an SQL buffer, for instance to do multiple 'inserts'. I have also > worked with the idea of being able to insert arbitrary text into > the buffer, so you can build dynamic SQL statements (for instance, > adding [or leaving out] a 'where' clause, or a 'limit/offset' clause). > > If we do it the way you are asking for, there would be no way to > insert more than a single statement into the SQL buffer. The cold inlet would be an append operation, so to build up the message, you would just keep sending chunks to the cold inlet, then when the whole thing is ready, send [submit( to the hot inlet. > > > This would allow for the comma trick, etc. and I think it would fit > better into Pd's message processing. In addition, there could be a > single line message for the hot inlet, like this: > > "submit insert into mine (name) values ('the_text')" > > I'll help implement this if you want. I just have a strong > aversion to the "sqlend" stuff since I think it could end up being > strange to use within Pd. Plus I think these are very valuable > objects to have, so I think it's important to get the interface > right. Basically, I am thinking of something along the lines of > the [textfile] interface, as much as possible. Here's a sketch: > > Why is it strange? We can't use the characters ',' and ';' due to > PD, so we have to come up with some other way of dealing with them. > > Also, how would you handle something like this... (using your method) > > "submit insert into mine (id, name, something) values (1, 'santa', > 'more stuff')" > > How would your external know when to actually submit the SQL buffer > to the database, as this is actually a series of 5 PD messages > being sent to the external? > > > __hot inlet__ > [open $1( > [close( > [export $1( - this could be used to export the database to a .sql > file > > [clear ( > [submit ( > [submit insert into mytable (name) values ('$1') ( > > > __cold inlet__ > [insert into mytable (name) values ('$1') ( > [CREATE TABLE datatable(id INTEGER, duration FLOAT, type VARCHAR, > datetime DATETIME) ( > [SELECT id, ABS((duration - 1500)/1500) AS error FROM datatable > ORDER BY error LIMIT 1( > > And the cold inlet would actually get these PD message... > > insert into mytable (name) values ('$1') > CREATE TABLE datatable(id INTEGER > duration FLOAT > type VARCHAR > datetime DATETIME > SELECT id > ABS((duration - 1500)/1500 AS error FROM datatable ODER BY ERROR > LIMIT 1 > > Exactly how would the external know when to terminate an SQL > statement and insert a semi-colon? There really is nothing there to > indicate that there is more than one SQL statement. On the cold inlet, everything would just be appended to the binbuf. Then when a [submit( is sent on the hot inlet, the whole binbuf would be dumped to the database with a semi-colon appended. So basically, you tell it where the semi-colon is. The [clear( message to the hot inlet would set the binbuf to blank. The above examples are meant to be a list of example messages, not necessarily execution order. Sorry, I wasn't more clear. The example patch should be much clearer. > > > Also, on a different note, I think it could be useful to have > various status and meta data queries output on the second inlet. > Currently in [psql], there is just a bang on complete. But there > could be things information about the database that aren't > available via SQL. > > SQLite already does this. Any messages coming back from the > database are output as a list on the second outlet. There are also > symbols that are output, more or less as a good indication > (indicating that a statement processed, for things that don't > return a result set). A bang on the second outlet indicates that > the current result set has been exhausted. > One other thing that I have thought about is other database layers, > upon submitting an INSERT, will return the ROWID of the row that > was just inserted. I was thinking that to implement this, this > number could be output on the second outlet as a float. > > So this would be: > > bang: indicates result set done > symbol/list: status message from database > float: ROWID of the last insert You might be interested in the Max/MSP external [mysql]: http://www.publicbeta.cx/maxx/ it has three outlets: data - "number of affected rows" - "bang when done" > > > Finally, there is the source code for the Max/MSP mysql external, > so I think it should be pretty easy to make a mysql version of this > interface as well. Then we'll have a nice trio of SQL options: > embedded, PGSQL, and MySQL. > > Well, as far as this goes, I think we should make every effort to > have the interfaces for ALL of these objects be the same, so that > these databases can be swapped on the fly. > I agree, I think it should be possible. The network connection stuff won't be needed in [sqlite] though, so that would be different. .hc ------------------------------------------------------------------------ ---- Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith

1 0

pd and max (2)
by marius schebella 08 Dec '07

08 Dec '07

hi, after all the complaining, here is a list of features that are special to pd. * open source: you can always dig into the deep universe of code to see how things are done. and change things according to your needs * no licencing: that means you don't pay money to be allowed to program in pd. (the player is free also in max). but it also means that you don't have to fiddle around with the licence when you install (which usually takes a day) or that you licence can expire or that you will have to redo this when you buy new hardware. * no messing around with floats and ints. no mistakes because you forget a dot (for example in [/ 10.]) that also includes that you can create arithmetic operators without arguments. whereas in max the default is integer. which means you cannot just type [/]. * possibility to edit abstractions! in max you always have to open the abstraction itself which is more than annoying. * possibility to save your patch with an open subpatch window in the front. (max thinks, you want to save the subpatch as a seperate new patch...) * no list object (ok, there is [zl reg]) * no [t a b] * as far as I know no settable sliders. (slider 200 will have a fixed size and a fixed scale (0-199 - linear) (might be wrong with that). * no keyboard shortcuts to create objects/messages (ctl+1...). there is a max toolbox, but that does not work reliable. unpack does not work for symbols in max. (but I am sure you can do that somehow else) diffs: two things that are different in max: [trigger 5 b] takes 5 as a number and not as a selector. when you bang it, even when you feed in another int, it will still output 5 and not zero as in pd. messages also remember their last value that you sent through them, so if you bang a message [$1 $2( it will spit out the last values and not 0 0. (only at the beginning as default) * max does not run on linux ... m.

8 10

Fwd: [psql] object hand-holding
by Mike McGonagle 08 Dec '07

08 Dec '07

---------- Forwarded message ---------- From: Mike McGonagle <mjmogo(a)gmail.com> Date: Dec 7, 2007 7:24 PM Subject: Re: [PD] [psql] object hand-holding To: Hans-Christoph Steiner <hans(a)eds.org> On Dec 7, 2007 6:44 PM, Hans-Christoph Steiner <hans(a)eds.org> wrote: > > Since both the current Pd-SQL devs (Mike and Jamie :) have posted to this > thread, I want to bring up the interface again. What do you guys think > about the two inlet interface for SQL objects? I just find the sql/sqlend > thing very strange, and it could end up being difficult to work with. I see > the interface like this: the hot inlet is for meta commands, like "open", > "close", "export", "connect", etc. Then the second, cold inlet is for > building SQL queries. Having a cold inlet devoted to building SQL queries > would mean that you would not need any special "sql/sqlend" style tags at > all. > Hans, I still think you are missing the point. The end tag 'endsql' and 'submitsql' are needed so that we can reinsert the commas that PD strips out of the messages. Without having the end tag, there would be no way to tell exactly where the SQL statement ends. And as far as it being difficult to work with, I just think of the closing tag as being a replacement for a semi-colon in the SQL. Pretty much everything else between the two tags is assumed to be PURE SQL, and gets placed into the SQL buffer. As PD splits up the messages based on where the comma's fall, we are assuming that each time the 'anything' method gets called, that we have to reinsert the comma into the SQL. The doesn't happen with the first 'sql' tag. As far as the second inlet, I can see doing that, but only for the reason that this 'syntax' is a little different than what PD normally expects. Other than that, I really don't see any reason to have a second inlet. > Instead, you'd just send messages to the cold inlet, those messages would > be appended to the existing SQL message buffer. Then when the query is > ready to be sent, send a "submit" or "run" or whatever to the hot inlet, and > it would run the buffer from the cold inlet and clear it. There would also > be a "clear" command to just clear the buffer without sending it. > So, then, how would we allow the ability to insert multiple SQL statements into a single buffer? The point of having the sql/endsql tag pairs is to delimit a single statement. I don't think that Jamie's external will allow multiple statements, I could be wrong, but I think it would be very desirable to have the ability to build an SQL buffer, for instance to do multiple 'inserts'. I have also worked with the idea of being able to insert arbitrary text into the buffer, so you can build dynamic SQL statements (for instance, adding [or leaving out] a 'where' clause, or a 'limit/offset' clause). If we do it the way you are asking for, there would be no way to insert more than a single statement into the SQL buffer. > This would allow for the comma trick, etc. and I think it would fit better > into Pd's message processing. In addition, there could be a single line > message for the hot inlet, like this: > > "submit insert into mine (name) values ('the_text')" > > I'll help implement this if you want. I just have a strong aversion to > the "sqlend" stuff since I think it could end up being strange to use within > Pd. Plus I think these are very valuable objects to have, so I think it's > important to get the interface right. Basically, I am thinking of something > along the lines of the [textfile] interface, as much as possible. Here's a > sketch: > Why is it strange? We can't use the characters ',' and ';' due to PD, so we have to come up with some other way of dealing with them. Also, how would you handle something like this... (using your method) "submit insert into mine (id, name, something) values (1, 'santa', 'more stuff')" How would your external know when to actually submit the SQL buffer to the database, as this is actually a series of 5 PD messages being sent to the external? > __hot inlet__ > [open $1( > [close( > [export $1( - this could be used to export the database to a .sql file > > [clear ( > [submit ( > [submit insert into mytable (name) values ('$1') ( > > > __cold inlet__ > [insert into mytable (name) values ('$1') ( > [CREATE TABLE datatable(id INTEGER, duration FLOAT, type VARCHAR, datetime > DATETIME) ( > [SELECT id, ABS((duration - 1500)/1500) AS error FROM datatable ORDER BY > error LIMIT 1( > And the cold inlet would actually get these PD message... insert into mytable (name) values ('$1') CREATE TABLE datatable(id INTEGER duration FLOAT type VARCHAR datetime DATETIME SELECT id ABS((duration - 1500)/1500 AS error FROM datatable ODER BY ERROR LIMIT 1 Exactly how would the external know when to terminate an SQL statement and insert a semi-colon? There really is nothing there to indicate that there is more than one SQL statement. > > Also, on a different note, I think it could be useful to have various > status and meta data queries output on the second inlet. Currently in > [psql], there is just a bang on complete. But there could be things > information about the database that aren't available via SQL. > SQLite already does this. Any messages coming back from the database are output as a list on the second outlet. There are also symbols that are output, more or less as a good indication (indicating that a statement processed, for things that don't return a result set). A bang on the second outlet indicates that the current result set has been exhausted. One other thing that I have thought about is other database layers, upon submitting an INSERT, will return the ROWID of the row that was just inserted. I was thinking that to implement this, this number could be output on the second outlet as a float. So this would be: bang: indicates result set done symbol/list: status message from database float: ROWID of the last insert > Finally, there is the source code for the Max/MSP mysql external, so I > think it should be pretty easy to make a mysql version of this interface as > well. Then we'll have a nice trio of SQL options: embedded, PGSQL, and > MySQL. > Well, as far as this goes, I think we should make every effort to have the interfaces for ALL of these objects be the same, so that these databases can be swapped on the fly. Mike -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician

1 0

← Newer
1
...
16
17
18
19
20
21
22
23
24
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 December 2007