Re: [PD] channels and dac
Roman Haefeli wrote: however, you can easily find out, what you need to send by eavesdroping on the 'pd channel': [r pd] | [print] then choose the desired settings in the menu and click 'ok'. as soon as you click ok, you'll see the message (and its format) in the pd-console. Nice! However I can't seem to get it working. With the above setup I get the following printed when I change channels to 10: print: audio-dialog 0 0 0 0 10 0 0 0 0 0 0 0 2 0 0 0 44100 50 So I pasted this (without print: into a message-box and was expecting channels to be set to 10 when I clicked on it. However this doesn't happen. Are my expectations wrong or am I missing something? -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions inline: Screenshot.png___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] settable send (pd 0.40+)
to follow on from a previous thread, how does the settable send work in pd 0.40 (i haven't installed it yet) if it is just like: [set x( | [send y] then, won't this break backwards compatibility? i often use [send] to pass set messages on, particularly for example when using [tabread4~] ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] channels and dac
Atte André Jensen wrote: Roman Haefeli wrote: however, you can easily find out, what you need to send by eavesdroping on the 'pd channel': [r pd] | [print] then choose the desired settings in the menu and click 'ok'. as soon as you click ok, you'll see the message (and its format) in the pd-console. Nice! However I can't seem to get it working. With the above setup I get the following printed when I change channels to 10: print: audio-dialog 0 0 0 0 10 0 0 0 0 0 0 0 2 0 0 0 44100 50 So I pasted this (without print: into a message-box and was expecting channels to be set to 10 when I clicked on it. However this doesn't happen. Are my expectations wrong or am I missing something? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list You need to send the message to pd, therefore it should be something like: [;pd audio-dialog 0 0 0 0 10 0 0 0 0 0 0 0 2 0 0 0 44100 50( Prepend ;pd to the messagebox, basically. (or conencting your message box to [s pd] should also work. Batuhan ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pddp drafts
Roman Haefeli wrote: On Mon, 2007-09-17 at 16:59 +0200, IOhannes m zmoelnig wrote: hard off wrote: i got it! a settable send using only pd vanilla objects. why don't you just use [send] instead of [setsend]? i don't see any added functionality in this abstraction (but an added dependency on the abstraction) are you reading the list? yes i am. it's about to overcome the problem, that the settable [send] is an only =0.40 feature. i am not talking about using the new (set) feature of [send], but about replacing [setsend] with [send]. have you had a look at [setsend]? [inlet] | [send $1] which is a wrapper for [send]: it has the very same functionality (in any version of pd) fmadsr. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pddp drafts
marius schebella wrote: that's not working anymore, because the send does not have $0- marius. ?? [sentsend] has no $0- either. at least: the new patch is working fine here. mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] settable send (pd 0.40+)
hard off wrote: to follow on from a previous thread, how does the settable send work in pd 0.40 (i haven't installed it yet) if it is just like: [set x( | [send y] then, won't this break backwards compatibility? i often use [send] to pass set messages on, particularly for example when using [tabread4~] no, luckily it is not like that (even though people kept requesting it :-)) (that is exactly what i was referring to in my sidekick on set-able sends) it is like: ... [symbol newname( | | [send ] that is: if your create a [send] object without(!) a send-name, it will have a second inlet which can be used to set the send-name. whatever(!) you send to the first inlet (including set bla) will be send to the receiver. so you can seafely upgrade to 0.40 (and you really should do so; it is very nice...) mfg.asdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] settable send (pd 0.40+)
ah good. thanks for clearing that up. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] making more rradical objects
On 9/17/07, Kevin McCoy [EMAIL PROTECTED] wrote: Hey Luke, that would be great if you could show me some of that, I would really appreciate it. OK, I dug up the code. I'm just including my full-blown careGUI replacement, but the only change necessary for this is the [t b b] split from the save button, with the right bang banging [s SAVE_PREP] before actually sending the save message to [caretaker]. The SAVE_PREP then bangs some zexy objects (I think they're zexy), which grab the size and contents of the array and put them into commun, so the when the left bang (from the t b b described above) fires, the data is in commun and waiting to be written. On load, I split off the table size parameter to resize the table (in case it's been resized since), then dump the data back in with [tabset] (again, I think from zexy). You could definitely achieve this without any of those externals; I just figured they'd be faster. I'll leave that as an exercise : ). Hope that helps! Luke ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] making more rradical objects
Um, mail clients should search for the words I'm including or attached is and yell at the user when they forget to do so : ). On 9/18/07, Luke Iannini (pd) [EMAIL PROTECTED] wrote: On 9/17/07, Kevin McCoy [EMAIL PROTECTED] wrote: Hey Luke, that would be great if you could show me some of that, I would really appreciate it. OK, I dug up the code. I'm just including my full-blown careGUI replacement, but the only change necessary for this is the [t b b] split from the save button, with the right bang banging [s SAVE_PREP] before actually sending the save message to [caretaker]. The SAVE_PREP then bangs some zexy objects (I think they're zexy), which grab the size and contents of the array and put them into commun, so the when the left bang (from the t b b described above) fires, the data is in commun and waiting to be written. On load, I split off the table size parameter to resize the table (in case it's been resized since), then dump the data back in with [tabset] (again, I think from zexy). You could definitely achieve this without any of those externals; I just figured they'd be faster. I'll leave that as an exercise : ). Hope that helps! Luke SaveArray.pd Description: Binary data sft.careGUI.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pddp drafts
On 18/09/2007, at 6.41, Hans-Christoph Steiner wrote: http://eds.org/~hans/template-HCS.png Nice work Hans. I really like the graphical cut down. I surgest to cut away the symbols to explain what inlet (outlet) are in question for the horizontal part. Reason: it's not really needed, hence contrary to the design ideas you have been applying. And it (cutting them) will serve more space on the right side for text/info. And last, it might just work for 'float' but might well not work for other more cluttered object-classes. I'm talking about those: | [float] | [float] [float] | ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] getting cue/loop points from WAV files
the workaround i have at the moment is that audacity lets you export cue points as a .txt file. As long as you don't add any labels to your cue points, then that text file contains a list of cue point times which you can read directly into an array in pd. in audacity, do the following: Project - New Label Track select your cue points (Add Label at Selection) File - Export Labels however, a pd object to read the cue points from .wav or .aiff files would be very useful. from what i have been reading, all the cue points are stored as a single line of data in the header of the file. here's a cue point reader as a supercollider patch: http://www.create.ucsb.edu/pipermail/sc-users/2006-November/029666.html ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] channels and dac
Batuhan Bozkurt wrote: You need to send the message to pd, therefore it should be something like: [;pd audio-dialog 0 0 0 0 10 0 0 0 0 0 0 0 2 0 0 0 44100 50( Prepend ;pd to the messagebox, basically. (or conencting your message box to [s pd] should also work. Thanks, that works great! -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] future of externals (was Re: pddp drafts)
I'm contributing playing to lotery every some time, if I win my idea is to buy Max rights and convert it in opensource :P 2007/9/18, Hans-Christoph Steiner [EMAIL PROTECTED]: On Sep 17, 2007, at 2:04 PM, victor wrote: But in the future there will be standard libraries which do not exist yet. these standard libraries will be structured like standard libraries in other programming languages. when?, my life is short Contributions welcome! :D .hc ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list If you are not part of the solution, you are part of the problem. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] settable send (pd 0.40+)
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: that is: if your create a [send] object without(!) a send-name, it will have a second inlet which can be used to set the send-name. Which reminds me: Why was it made so that only sends without argument get the second inlet? I don't see why it wouldn't be possible to have every send have a second inlet to set the receiver. It's easy to achieve with an abstraction (as attached) but that seems unnecessary work to me. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ssend-help.pd Description: application/puredata ssend.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pddp drafts
hola, I am following this reference templates discussion because I'm interested in the pd documentation project. I have only some side comments about colors, I think -if used, colors should be kept to accentuate content. This was said before but also in my view pd objects in reference patches should not be colored. I do think that colors help to remember things so it would be helpful to use them in order to remember families of objects or other categories. I did some exercise using colors to emphasize sections, making minor changes to template 9 from Ben - In order to have some constraint to choose I used a color palette -I borrowed filterbank~ colors for this. http://ljudmila.org/~pueblo/box/constructivism/template9_a.png previous try: http://ljudmila.org/~pueblo/box/constructivism/template7_aaa.png http://ljudmila.org/~pueblo/box/constructivism/color_palette.png It is only an exercise I just wanted to note that the decision of using colors is sensitive, we associate many things to them and this becomes important when you are learning. I specially have problems with the use of gray which I associate with the obvious gray skies, pigeons and dictatorship (chilean style) I'm not a graphic designer but I sense some relation between pd and constructivism/suprematism so this could also be an inspiration for color and form... http://ljudmila.org/~pueblo/box/constructivism/malevich-st-1916.jpg http://ljudmila.org/~pueblo/box/constructivism/lissitzky-mayakovsky.jpg http://ljudmila.org/~pueblo/box/constructivism/rodchenko-mayak-nipple.jpg http://www.poster.net/malevich-kasimir/malevich-kasimir-black-rectangle-blue-triangle-1915-3500626.jpg thanks for the good work and hope to join you in the chat discussion in some hours from now. best wishes, alejandra ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glsl examples
hello, i upload a new version with some new exemples (and remove the one i did not write) : http://drpichon.free.fr/glsl_20070918.zip cyrille marius schebella a écrit : Hi (Cyrille), it seems this link is broken, can someone help me out? http://drpichon.free.fr/gem_glsl_ch_200070617.zip marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Frank Barknecht wrote: Hallo, Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the purepd or list-abs collections). as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) fma.dsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: This all sounds excellent, I think this is exactly what would work well. As for choosing standard namespace names, I think that we should follow the lazy consensus rule, with required discussion, i.e., standard lib names should not be automatically accepted unless there is discussion. I think there is need for discussion when it comes to the classes in standard lib names, as I think, that the std-namespace(s) require(s) a more elaborated style guide/specification. Two issues come to my mind immediatly. One is that the behaviour of every of these std-objects needs to be discussed before they are finally released into the wild to avoid future complications and possibly incompatible changes and conflicting interfaces like we have with [counter]. (Matju probably would wisely recommend to add tests as well.) Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the purepd or list-abs collections). That's not because I don't like externals or would want to convince everyone to never touch an external, it's just that a std-library for a programming language should be self-contained. For example if you install Python, a Python programmer can rely on the fact, that all the modules delivered with the core-Python will definitely work. It's still possible to use additional Python modules, but of course none of the core-python modules depends on third-party modules like pyode etc. Pd distributions like pd-extended or the packages included in the various Linux-distributions may still opt to ship optimized implementations of the std-library classes that use externals. I've already mentioned as an example two versions of [list-drip]: one using no externals as in list-abs and one just wrapping [zexy/drip]. Pd-extended could include the [list-drip] with [zexy/drip] as default, users of e.g. PDa would maybe use the list-abs version. However as a guideline I believe, that every std-class should have a purepd implementation, otherwise it should not be included in that namespace. As a side note I may add that finding solutions to some tricky problems under the additional restriction to only use builtin objects is a very satisfying experience. It makes you feel like a Master Of The Universe(tm) ;-) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] making -jack work [was: Re: channels and dac]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: this is the hack i use to get jack running, since '-jack' isn't working here and always having to open the menu is odd. Actually during pd~convention 2 I heard about a trick (from IOhannes or Matju?) to work around this bug: You also need to specify the number of channels, Pd should use. Then Pd will automatically connect and work even from the command line: $ pd -jack -channels 2 or $ pd -jack -inchannels 2 -outchannels 6 both work as expected (tested with pd-0.40). Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] GEM question: alpha values
hello list, I have a question concerning alpha values. with movies in GEM I found out so far how I can turn alpha on/off with the alpha-object and a toggle in the right inlet. so is ti possible to have an adjustable range of alpha? with a v-slider? couldnt find a way, so I dont know if it is possible at all ... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo! as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM question: alpha values
try [coloRGB 1 1 1 1] with a value from 0 to 1 in the rightmost inlet. a 2007/9/18, henrik wurster [EMAIL PROTECTED]: hello list, I have a question concerning alpha values. with movies in GEM I found out so far how I can turn alpha on/off with the alpha-object and a toggle in the right inlet. so is ti possible to have an adjustable range of alpha? with a v-slider? couldnt find a way, so I dont know if it is possible at all ... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Alexandre Quessy http://alexandre.quessy.net http://www.puredata.info/Members/aalex ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glsl examples
Hello Cyrille, Small problem here (PowerBook G4, PD extended 39.2 rc3, Gem 0.91-cvs, GeForce FX Go5200) : - 'fractal.pd' in 'fractal' folder doesn't work : black screen but no error. - 'noise.pd' in 'fractal_noise_with_texture' folder doesn't work : error _glsl_frag noise ... couldn't create (and if i use _glsl.pd as abstraction, there is an error) - 'texture.pd' in 'newWave-alpha' folder doesn't work : error [glsl_vertex] : ERROR: 0:1: '/' : syntax error parse error ERROR: Parser found no code to compile in source strings error : [glsl_vertex]: shader not loaded idem for [glsl_fragment] - [glsl_program]: Link failed! Hope, it wil help you ! Jack Le 18 sept. 07 à 13:05, cyrille henry a écrit : hello, i upload a new version with some new exemples (and remove the one i did not write) : http://drpichon.free.fr/glsl_20070918.zip cyrille marius schebella a écrit : Hi (Cyrille), it seems this link is broken, can someone help me out? http://drpichon.free.fr/gem_glsl_ch_200070617.zip marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM question: alpha values
It would be interresting that you have a look in the help/browser/ reference/Gem/alpha.pd before to post any message here. This post is like a spam. thx henrik. Jack Le 18 sept. 07 à 14:18, henrik wurster a écrit : hello list, I have a question concerning alpha values. with movies in GEM I found out so far how I can turn alpha on/off with the alpha-object and a toggle in the right inlet. so is ti possible to have an adjustable range of alpha? with a v-slider? couldnt find a way, so I dont know if it is possible at all ... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Georg Holzmann wrote: Hallo! as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. that is obviously the idea of the stdlib maintainers. nevertheless, it assumes that the auther of a certain object would happily give up their object and either maintain a stdlibized version or withdraw from maintaining the object alltogether (and someone else maintains the stdlibized version) i guess, the 1st option is the one we would want to see happen. nevertheless i have some doubts: often, objects can not simply be moved into the stdlib, but they should follow some standard (hence the name!) design principles (of the interface). but changing the interface of an object is a heavy modification, which needs a lot of social competence) (i am pretty sure that there are lots of ideas how to make objects in zexy more consistent with other objects, however i have spend a lot of time in designing the API (at least for some of them :-)) Pd-externals are usually FLOSS. this gives us the technical permission to duplicate the code. it is not necessarily a social permission. mfgad.sr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM question: alpha values
In reference/Gem, the patch 'alpha.pd' contain an object call [color 0 1 0 0.5] with a number box on its right. Move the value of this number box between 0 and 1 (use the shift key). And that all. Jack Le 18 sept. 07 à 15:28, henrik wurster a écrit : I am sorry, jack, but I actually did look in the help and couldnt find any direct reference to alpha range, but only how to turn alpha on and off... 2007/9/18, Jack [EMAIL PROTECTED]: It would be interresting that you have a look in the help/browser/ reference/Gem/alpha.pd before to post any message here. This post is like a spam. thx henrik. Jack Le 18 sept. 07 à 14:18, henrik wurster a écrit : hello list, I have a question concerning alpha values. with movies in GEM I found out so far how I can turn alpha on/off with the alpha-object and a toggle in the right inlet. so is ti possible to have an adjustable range of alpha? with a v-slider? couldnt find a way, so I dont know if it is possible at all ... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list gem_alpha_help.png ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] glsl examples
Le 18 sept. 07 à 15:39, cyrille henry a écrit : Jack a écrit : Hello Cyrille, Small problem here (PowerBook G4, PD extended 39.2 rc3, Gem 0.91- cvs, GeForce FX Go5200) : - 'fractal.pd' in 'fractal' folder doesn't work : black screen but no error. this as allready been reported, i can't understand why it's not working. maybee your hardware does not understand the loop is the shader code. - 'noise.pd' in 'fractal_noise_with_texture' folder doesn't work : error _glsl_frag noise ... couldn't create (and if i use _glsl.pd as abstraction, there is an error) oups, i put the wrong abstraction. here is the good one. But the problem persist, black screen without error. - 'texture.pd' in 'newWave-alpha' folder doesn't work : error [glsl_vertex] : ERROR: 0:1: '/' : syntax error parse error ERROR: Parser found no code to compile in source strings error : [glsl_vertex]: shader not loaded idem for [glsl_fragment] - [glsl_program]: Link failed! try to manually open the shader. Manually ok, but also black screen without error. grrr ! I think that my graphics card is too light to do that ! Jack cyrille Hope, it wil help you ! Jack Le 18 sept. 07 à 13:05, cyrille henry a écrit : hello, i upload a new version with some new exemples (and remove the one i did not write) : http://drpichon.free.fr/glsl_20070918.zip cyrille marius schebella a écrit : Hi (Cyrille), it seems this link is broken, can someone help me out? http://drpichon.free.fr/gem_glsl_ch_200070617.zip marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list _glsl_frag.pd.zip ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] GEM GLSL patch vertex displacement mapping
Hello, i really don't know if this .vert and .frag (from ozone3D.net) are good to do vertex displacement mapping with this patch. And i don't know if this patch is good with [rubber]. My card doesn't accept this program (so i can't test), yours maybe. thx to have a look. Jack texture.pd Description: Binary data my.frag Description: Binary data my.vert Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM question: alpha values
I dont want to spam your list...ppl have been verhy helpful. but I wouldnt spam, sometimes I just overlook something in the doc 2007/9/18, Frank Barknecht [EMAIL PROTECTED]: Hallo, Jack hat gesagt: // Jack wrote: This post is like a spam. I guess, even IOhannes and me managed to say RTFM in a friendlier way. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM question: alpha values
Hallo, Jack hat gesagt: // Jack wrote: This post is like a spam. I guess, even IOhannes and me managed to say RTFM in a friendlier way. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] settable send (pd 0.40+)
i guess it would help for debugging of newer patches on older versions of pd. if you create [send x] and feed it [symbol x] [symbol y] symbol z], then it will always send to x in older versions of pd, so it might be harder to find the source of error. however, if you just create [send], it will send to nowhere, so it will be easier to track down the point where message flow breaks down. another related question, do receives also have this set function in pd 0.40? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Multiple Arduino Bluetooths
Has anyone tried running three arduino bluetooth devices at the same time through a PD patch. Are there any problems. Thanks Paul ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] simple message/list parsing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Sep 16, 2007 at 05:20:34PM +1000, Mat Wall-Smith wrote: Hi.. I'm still looking for a way of checking one list of numbers against another list of numbers and returning the any number that is included in both. Something like the [select] object but that passes the number rather than a bang so I could add the number to a text file or list. Install the python external, and make a simple extraction that does this? [ x for x in set1 if x in set2 ] /me ducks - -ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG7/7ne8HF+6xeOIcRAkdaAKCEQFFHWvoXPVBgETV41nYvBUPHzQCggxVA 5AN5YUVkkpOclVQ57VpFJPg= =mk55 -END PGP SIGNATURE- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [; pd init(
When I send 'init' to pd i get this printed to the console: consistency check failed: glob_initfromgui And then Pd gets in-functional. All I can is to shut the gui from the menu, but a pd process keeps running and uses like 60% cpu time. I don't know the correct term to describe this behavior. I wonder why it happens. I find it quite not-nice if Pd tilts by such a thing, but there might be reasons i know nothing about? I can file a bug/feature report, but was curious if it is a just me... Setup: Pd 0.40-2 from Miller's site, intel (core duo) mac. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Frank Barknecht wrote: Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: I think it would be more useful right now if pd would search in subdirectories. For instance there are about 70 directories in pd/extra (Pd version 0.40.3-extended-20070905), and only 10 lines in the path dialog...not to mention the time wasted typing in every single path. At the moment most of the help files are not found and the objects don't work unless they are prefixed with their path, like [mrpeach/oscsend]. It looks like the function do_open_via_path in s_path.c is the one to fix... This might break some stuff. For example I often use private subdirectories whose objects should *not* be available globally. What if pd searched deeply only in the extra directory, then you could put private files elsewhere and they would not be found? The do_open_via_path function already treats 'extra' as a special case, only searching it after all else fails. Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pddp drafts
ok, finally after testing with my pddp draft, it does not work. I think it is because it is not fast enough. when I use it in combination with textfile and a loop, then I get a lot of error messages, nothing is scripted to the subpatch, or maybe only the first message (clear) but the rest not? too bad. marius. IOhannes m zmoelnig wrote: marius schebella wrote: that's not working anymore, because the send does not have $0- marius. ?? [sentsend] has no $0- either. at least: the new patch is working fine here. mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [; pd init(
On Tue, 18 Sep 2007, Miller Puckette wrote: init is one of many messages that Pd and its gui send back and forth, which aren't intended to have any user-level functionality... of course, some of those messages like connect have proved useful at the user level; but none of them are guaranteed to do anything useful or even to be safe. The only one that's supported is dsp for turning audio computation on and off. It's not supported, not guaranteed and not intended to be used, yet if you'd remove support for that, people would scream like crazy. It's a bit like illegal immigrants: the state won't give them an official status and the state can't function without them. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] ogg externals
hello, how i can install ogg libs for osx??? my pd don't find libogg.0.dylib and others... thanks Andrés Ferrari G. http://puredata.org/Members/anfex __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Frank Barknecht wrote: Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). I think it would be more useful right now if pd would search in subdirectories. For instance there are about 70 directories in pd/extra (Pd version 0.40.3-extended-20070905), and only 10 lines in the path dialog...not to mention the time wasted typing in every single path. At the moment most of the help files are not found and the objects don't work unless they are prefixed with their path, like [mrpeach/oscsend]. It looks like the function do_open_via_path in s_path.c is the one to fix... Martin Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), the rights to Max/Msp would not have to be bought (as this is clearly the feature that most Max/Msp features adore: to install an external, simply put it in the external folder, and voilà, done). Tom On 9/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Frank Barknecht wrote: Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). I think it would be more useful right now if pd would search in subdirectories. For instance there are about 70 directories in pd/extra (Pd version 0.40.3-extended-20070905), and only 10 lines in the path dialog...not to mention the time wasted typing in every single path. At the moment most of the help files are not found and the objects don't work unless they are prefixed with their path, like [mrpeach/oscsend]. It looks like the function do_open_via_path in s_path.c is the one to fix... Martin Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM GLSL patch vertex displacement mapping
Hi all, this brings me to a question that has bugging me for some time: Can (vertex) shader programs have a knowledge of time? This would make it possible to move around objects using shaders. I can imagine that it's possible to increment counters (in graphics card memory) across shared calls, but in addition it has to be possible to calibrate these time steps (unsusceptible to varying GPU load). any ideas? greetings, Thomas Am 18.09.2007 um 16:27 schrieb [EMAIL PROTECTED]: Hello, i really don't know if this .vert and .frag (from ozone3D.net) are good to do vertex displacement mapping with this patch. And i don't know if this patch is good with [rubber]. My card doesn't accept this program (so i can't test), yours maybe. thx to have a look. Jack texture.pd my.frag my.vert ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] simple message/list parsing
On Tue, 18 Sep 2007, Ken Restivo wrote: Install the python external, and make a simple extraction that does this? [ x for x in set1 if x in set2 ] Install the ruby external, and make a simple external that does this? set1 set2 and does it all in linear time too, instead of (presumably) quadratic. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] simple message/list parsing
Am 18.09.2007 um 21:34 schrieb Mathieu Bouchard: On Tue, 18 Sep 2007, Ken Restivo wrote: Install the python external, and make a simple extraction that does this? [ x for x in set1 if x in set2 ] Install the ruby external, and make a simple external that does this? set1 set2 and does it all in linear time too, instead of (presumably) quadratic. it's the exact same syntax for Python (starting with version 2.4) greetings, Thomas ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] simple message/list parsing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Sep 18, 2007 at 10:22:25PM +0200, Thomas Grill wrote: Am 18.09.2007 um 21:34 schrieb Mathieu Bouchard: On Tue, 18 Sep 2007, Ken Restivo wrote: Install the python external, and make a simple extraction that does this? [ x for x in set1 if x in set2 ] Install the ruby external, and make a simple external that does this? set1 set2 and does it all in linear time too, instead of (presumably) quadratic. it's the exact same syntax for Python (starting with version 2.4) Thanks. I haven't done much with Python since the 2.3 days. Um, actually, it looks like it's more like: list( set(set1) set(set2) ) But, anyway, back to PD now. :-) Time for me to try to get RRAD running and play with it some. - -ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG8DbWe8HF+6xeOIcRAr8oAJ9KPNYYWgY1u4dq/yoQzmT72TjWEQCg+wNy KHFwR9v5ywkQi7sGe+1QhEg= =0eQx -END PGP SIGNATURE- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: What if pd searched deeply only in the extra directory, then you could put private files elsewhere and they would not be found? The do_open_via_path function already treats 'extra' as a special case, only searching it after all else fails. It would be the same: For example I use a private subdir in sssad which already is install in extra. AFAIR this topic was discussed some times on pd-dev. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 18, 2007, at 11:04 AM, Frank Barknecht wrote: Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. Yes, that would be the idea for binaries in the std-lib. But as the others convinced me at the pd conv I don't think that this will happen soon (and soon in pd time means maybe 8-10 years ... ;) Depends on how you define this: I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther (flatspace in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions). It's all a matter of perspective. I use [comport] all the time and really want a [io/serial] that is based on comport, but has a clean, standardized interface in common with all IO objects (i.e. same basic messages, inlets, outlets, etc.). I have never used [drip], so it doesn't matter to me whether that was included now or in 10 years. Whether iem/comport is maintained is also a non-issue. If someone wants to do the work to maintain both, why stop them? .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list kill your television ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Multiple Arduino Bluetooths
It should work, but I haven't tried it. Let us know how it goes. .hc On Sep 18, 2007, at 12:18 PM, Paul Verity Smith wrote: Has anyone tried running three arduino bluetooth devices at the same time through a PD patch. Are there any problems. Thanks Paul ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] getting cue/loop points from WAV files
Cool, thanks for the info. I am sure there are a dozen free C implementations of this, it's just a matter of getting that into a Pd object. Any volunteers? :D .hc On Sep 18, 2007, at 6:42 AM, hard off wrote: the workaround i have at the moment is that audacity lets you export cue points as a .txt file. As long as you don't add any labels to your cue points, then that text file contains a list of cue point times which you can read directly into an array in pd. in audacity, do the following: Project - New Label Track select your cue points (Add Label at Selection) File - Export Labels however, a pd object to read the cue points from .wav or .aiff files would be very useful. from what i have been reading, all the cue points are stored as a single line of data in the header of the file. here's a cue point reader as a supercollider patch: http://www.create.ucsb.edu/pipermail/sc-users/2006-November/ 029666.html Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), If it was implemented, which one would become [once]: extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd or maybe: extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd ? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Well, the examples with more than one folder depth are not of concern. Just limit the search to one depth. Also, asking the authors of the conflicting objects/abstractions is much less work than building a mega-meta-system. After, that, the cvs law could simply state that no now object/abstraction may have the same name at the first depth level (or second depth depending on your persepective). So only objetcts/abstractions named extra/*/*.pd, extra/*/*.dll, extra/*/*.pd_linux or extra/*/*.pd_darwin Also, please quoting pdmtl abstractions. If you require more information about them, please visit the documentation website. The cvs version is outdated, and since there is talking of making a svn system, they will be integrated properly then. Tom On 9/18/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), If it was implemented, which one would become [once]: extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd or maybe: extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd ? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] getting cue/loop points from WAV files
If you are interested, with the sample_id system, the pdmtl abstractions have a basic 4 cue point system i.e. start,end, loop in, loop out . Once you load a wav with the sample_id system you can load it many times without the actual sample(frame) data being reloaded. Since you can save the cuepoints, you can reload the same file with a different set of the 4 cues. For example, you can have a loop.wav file, that can be loaded as 16 samples each one having their different 4 cue points. Even thought in PD, you have 16 copies of the same sample, the actual audio data is only loaded once. Tom On 9/18/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Cool, thanks for the info. I am sure there are a dozen free C implementations of this, it's just a matter of getting that into a Pd object. Any volunteers? :D .hc On Sep 18, 2007, at 6:42 AM, hard off wrote: the workaround i have at the moment is that audacity lets you export cuepoints as a .txt file. As long as you don't add any labels to your cue points, then that text file contains a list of cue point times which you can read directly into an array in pd. in audacity, do the following: Project - New Label Track select your cue points (Add Label at Selection) File - Export Labels however, a pd object to read the cue points from .wav or .aiff files would be very useful. from what i have been reading, all the cue points are stored as a single line of data in the header of the file. here's a cue point reader as a supercollider patch: http://www.create.ucsb.edu/pipermail/sc-users/2006-November/029666.html Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM GLSL patch vertex displacement mapping
hello, yes, this .vert and frag works with your patch on my computer (i just need to change the 100.0 to 1.0) but vertex displacement is curently very slow. Chris should fix this soon, look at gem-dev archive for more details. cyrille [EMAIL PROTECTED] a écrit : Hello, i really don't know if this .vert and .frag (from ozone3D.net) are good to do vertex displacement mapping with this patch. And i don't know if this patch is good with [rubber]. My card doesn't accept this program (so i can't test), yours maybe. thx to have a look. Jack ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM GLSL patch vertex displacement mapping
OK, thx for the precision. Jack Le 18 sept. 07 à 23:52, cyrille henry a écrit : hello, yes, this .vert and frag works with your patch on my computer (i just need to change the 100.0 to 1.0) but vertex displacement is curently very slow. Chris should fix this soon, look at gem-dev archive for more details. cyrille [EMAIL PROTECTED] a écrit : Hello, i really don't know if this .vert and .frag (from ozone3D.net) are good to do vertex displacement mapping with this patch. And i don't know if this patch is good with [rubber]. My card doesn't accept this program (so i can't test), yours maybe. thx to have a look. Jack - --- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] bug-report, -channels
Hi I'm not sure it it's the right place to bring it up, but it seems theres a bug in .40 (linux). If I call pd -channels 4 -rt -jack file.pd it works, however the following makes pd segfault: pd -rt -jack -channels 4 file.pd I've spend most of tonight figuring this out, so if someone could verify it, I'd be most pleased... -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ogg externals
Try using the latest Pd-extended: http://at.or.at/hans/pd/installers.html .hc On Sep 18, 2007, at 1:57 PM, Andres Ferrari wrote: hello, how i can install ogg libs for osx??? my pd don't find libogg.0.dylib and others... thanks Andrés Ferrari G. http://puredata.org/Members/anfex __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 18, 2007, at 8:23 AM, IOhannes m zmoelnig wrote: Frank Barknecht wrote: Hallo, Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the purepd or list-abs collections). as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) They key difference would be that each stdlib would have a standardized interface, and each objectclass would conform to that interface. For example, there could be an 'io' standard lib. Everything in that lib would respond to [open(, [close(, etc. in the same way, the first inlet would behave similarly, and the first outlet would be the data in the form of lists, and the second outlet would be status info in the form of lists. So no, I don't think we should just copy over existing code without change. Instead, we should use existing code when it's useful, but focus on having a clean and consistent interface for each library. Then the old author's name libraries, like iem, zexy, ggee, etc. would remain in place for backwards compatibility. .hc fma.dsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)
On Sep 18, 2007, at 9:43 AM, IOhannes m zmoelnig wrote: Georg Holzmann wrote: Hallo! as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on 3rd party externals, but on stdlib internal libraries. (with duplicate code and everything that follows from it) As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport. that is obviously the idea of the stdlib maintainers. nevertheless, it assumes that the auther of a certain object would happily give up their object and either maintain a stdlibized version or withdraw from maintaining the object alltogether (and someone else maintains the stdlibized version) i guess, the 1st option is the one we would want to see happen. nevertheless i have some doubts: often, objects can not simply be moved into the stdlib, but they should follow some standard (hence the name!) design principles (of the interface). but changing the interface of an object is a heavy modification, which needs a lot of social competence) (i am pretty sure that there are lots of ideas how to make objects in zexy more consistent with other objects, however i have spend a lot of time in designing the API (at least for some of them :-)) They key difference would be that each stdlib would have a standardized interface, and each objectclass would conform to that interface. For example, there could be an 'io' standard lib. Everything in that lib would respond to [open(, [close(, etc. in the same way, the first inlet would behave similarly, and the first outlet would be the data in the form of lists, and the second outlet would be status info in the form of lists. So no, I don't think we should just copy over existing code without change. Instead, we should use existing code when it's useful, but focus on having a clean and consistent interface for each library. Then the old author's name libraries, like iem, zexy, ggee, etc. would remain in place for backwards compatibility. Pd-externals are usually FLOSS. this gives us the technical permission to duplicate the code. it is not necessarily a social permission. Why use a free license then? That just needlessly complicates things. If someone doesn't want people freely using their code, then they should say so overtly. Not, my license says you can use my code, but if you do, then I'll get mad and work against you. .hc mfgad.sr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If you are not part of the solution, you are part of the problem. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pddp drafts
Hey, Post those receive symbols that you wanted so that I can include them. .hc On Sep 18, 2007, at 2:07 PM, marius schebella wrote: ok, finally after testing with my pddp draft, it does not work. I think it is because it is not fast enough. when I use it in combination with textfile and a loop, then I get a lot of error messages, nothing is scripted to the subpatch, or maybe only the first message (clear) but the rest not? too bad. marius. IOhannes m zmoelnig wrote: marius schebella wrote: that's not working anymore, because the send does not have $0- marius. ?? [sentsend] has no $0- either. at least: the new patch is working fine here. mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Mistrust authority - promote decentralization. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GEM question: alpha values
Yes, it's true, it's a bit rude, i'm sorry for that. But I prefer that people search a little bit (5 minutes) before they post. I think that it would be better for them to learn pd and to understand it. And, of course, after a little search, it's good that people post and explain why they can't resolve the problem. Jack Le 18 sept. 07 à 19:30, Frank Barknecht a écrit : Hallo, henrik wurster hat gesagt: // henrik wurster wrote: I dont want to spam your list...ppl have been verhy helpful. but I wouldnt spam, sometimes I just overlook something in the doc To clarify what I meant to express: I didn't consider your question spam at all, and I think, Jack's comparison of your question to spam came across a bit rude. While the help file for alpha does indeed have a color object inside, it doesn't say clearly that this is the object that is responsible for changing the transparency. For a beginning user who doesn't yet know all the objects this is indeed very easy to overlook unless he played with all the sliders. It's good that you asked, keep on doing that. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] channels and dac
On Tue, 2007-09-18 at 08:55 +0200, Atte André Jensen wrote: Roman Haefeli wrote: however, you can easily find out, what you need to send by eavesdroping on the 'pd channel': [r pd] | [print] then choose the desired settings in the menu and click 'ok'. as soon as you click ok, you'll see the message (and its format) in the pd-console. Nice! However I can't seem to get it working. With the above setup I get the following printed when I change channels to 10: print: audio-dialog 0 0 0 0 10 0 0 0 0 0 0 0 2 0 0 0 44100 50 So I pasted this (without print: into a message-box and was expecting channels to be set to 10 when I clicked on it. However this doesn't happen. Are my expectations wrong or am I missing something? yo, sorry, i should have mentioned it, since its not self-explanatory. you need to send it back to pd, so do either this: [audio-dialog 0 0 0 0 10 0 0 0 0 0 0 0 2 0 0 0 44100 50( | [s pd] or, which is exactly the same: [; pd audio-dialog 0 0 0 0 10 0 0 0 0 0 0 0 2 0 0 0 44100 50( YO, N.B.: you need to send the audiosetapi message before you send the audio-dialog message. audio-dialog alone won't work i think. this has the bad side effect, that the audio-settings window pops up. i didn't find a solution yet to avoid this. has someone an idea? roman ___ Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] making -jack work [was: Re: channels and dac]
On Tue, 2007-09-18 at 12:33 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: this is the hack i use to get jack running, since '-jack' isn't working here and always having to open the menu is odd. Actually during pd~convention 2 I heard about a trick (from IOhannes or Matju?) to work around this bug: You also need to specify the number of channels, Pd should use. Then Pd will automatically connect and work even from the command line: $ pd -jack -channels 2 or $ pd -jack -inchannels 2 -outchannels 6 both work as expected (tested with pd-0.40). hey frank thanks a lot for bringing this up here. i am glad to hear that and also that it is not a longterm bug, but just an issue of how using it. works perfectly! i even found a solution, that works from the commandline: -send pd audio-setapi 5 -send pd midi-setapi 1 -send pd audio-dialog 0 0 0 0 8 0 0 0 0 0 0 0 8 0 0 0 44100 50 -send pd midi-dialog 1 0 0 0 1 0 0 0 1 1 though, i am very happy, that i don't need to use these lines anymore. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] inconsistencies with lib names (was: representning classes
Frank Barknecht wrote: Date: 2007/09/18 Tue PM 04:51:57 EDT To: pd-list@iem.at Subject: Re: [PD] inconsistencies with lib names (was: representning classes Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote: It looks like the function do_open_via_path in s_path.c is the one to fix... Wow, talk about solving a big problem with the most simple solution! If this were implemented (and that could be done in one day instead of years), If it was implemented, which one would become [once]: extra/purepd/once.pd extra/iemabs/once.pd extra/pdmtl/flow/once.pd or maybe: extra/iem/spatialization/VARESE/app/iemabs/once.pd extra/CUBEmixer/lib/libs/iemabs/once.pd The first one found would be the right one. It's not pd's problem if there exist more than one file with the same name. Surely that's up to the creators of the files to sort out. The alternative of using paths for each and every object is a massive kludge that's going to fall on your head and crush you sooner or later, at least I can already feel it pushing me into the mud :( [possibly/the/worst/idea/ever/invented/once] Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bug-report, -channels
On Wed, 2007-09-19 at 00:14 +0200, Atte André Jensen wrote: I'm not sure it it's the right place to bring it up, but it seems theres a bug in .40 (linux). If I call pd -channels 4 -rt -jack file.pd it works, however the following makes pd segfault: pd -rt -jack -channels 4 file.pd I've spend most of tonight figuring this out, so if someone could verify it, I'd be most pleased... hi atte i tried it here and both work. i am on linux with pd 0.40.2. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bug-report, -channels
Roman Haefeli wrote: i tried it here and both work. i am on linux with pd 0.40.2. Hmmm. It seems to happen only with the attached patch 04_dist_drums.pd (depends on the rest of the attached files, hope I didn't miss any). Anyone can reproduce this, then? Any idea if it's me or PD? -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions #N canvas 1460 309 450 300 10; #X obj 100 42 simple_sine; #X obj 10 12 loadbang; #X msg 10 33 \; pd dsp 1; #X obj 100 11 notein 1; #X obj 204 13 notein 2; #X obj 205 69 dac~ 3 4; #X obj 101 69 dac~ 1 2; #X obj 204 43 triangle_bass; #X connect 0 0 6 0; #X connect 0 1 6 1; #X connect 1 0 2 0; #X connect 3 0 0 0; #X connect 3 1 0 1; #X connect 4 0 7 0; #X connect 4 1 7 1; #X connect 7 0 5 0; #X connect 7 1 5 1; #N canvas 58 157 450 300 10; #X obj 72 82 phasor~; #X obj 72 102 *~ -1; #X obj 72 122 +~ 1; #X obj 125 108 min~; #X obj 71 178 outlet~; #X text 72 18 frequency; #X text 69 196 audio out; #X obj 72 37 inlet~; #X connect 0 0 1 0; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 3 1; #X connect 3 0 4 0; #X connect 7 0 0 0; #N canvas 511 218 424 347 10; #X obj 88 206 *~; #X obj 62 70 legato; #X obj 30 111 mtof; #X obj 48 32 inlet; #X obj 125 31 inlet; #X text 48 13 note; #X text 121 13 velocity; #X obj 42 253 outlet~; #X obj 135 252 outlet~; #X text 48 276 left; #X text 136 274 right; #X obj 122 128 adsr 0.1 5 500 50 50; #X obj 29 177 osc~; #X obj 30 132 pack 0 \$1; #X obj 30 154 line~; #X text 240 11 creation argument:; #X text 256 25 portamento time (ms); #X connect 0 0 7 0; #X connect 0 0 8 0; #X connect 1 0 2 0; #X connect 1 1 11 0; #X connect 2 0 13 0; #X connect 3 0 1 0; #X connect 4 0 1 1; #X connect 11 0 0 1; #X connect 12 0 0 0; #X connect 13 0 14 0; #X connect 14 0 12 0; #N canvas 509 106 450 300 10; #X obj 40 25 inlet; #X obj 184 23 inlet; #X obj 42 262 outlet~; #X obj 184 244 outlet~; #X obj 64 61 legato; #X obj 51 153 phasor~; #X obj 51 89 mtof; #X obj 51 109 pack 0 \$1; #X obj 51 129 line~; #X obj 51 173 *~ -1; #X obj 51 193 +~ 1; #X obj 104 179 min~; #X obj 175 110 adsr 1 5 500 50 50; #X obj 155 222 *~; #X obj 287 166 tri~; #X connect 0 0 4 0; #X connect 1 0 4 1; #X connect 4 0 6 0; #X connect 4 1 12 0; #X connect 5 0 9 0; #X connect 5 0 11 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 5 0; #X connect 9 0 10 0; #X connect 10 0 11 1; #X connect 11 0 13 0; #X connect 12 0 13 1; #X connect 13 0 3 0; #X connect 13 0 2 0; #N canvas 371 139 752 655 12; #X obj 105 111 inlet; #X obj 435 151 inlet; #X text 101 86 trigger; #X obj 105 139 sel 0; #X obj 244 155 t b; #X obj 166 264 f \$1; #X obj 166 289 pack 0 \$2; #X obj 492 151 inlet; #X obj 438 281 del \$2; #X obj 458 429 line~; #X obj 462 304 f \$4; #X obj 501 379 pack 0 \$3; #X obj 554 151 inlet; #X obj 616 151 inlet; #X obj 689 150 inlet; #X msg 105 170 stop; #X obj 612 306 pack 0 \$5; #X text 435 129 level; #X obj 501 355 * \$1; #X obj 458 454 outlet~; #X text 102 378 and pack with; #X text 103 398 attack time; #X text 31 126 if zero; #X text 32 143 release; #X text 12 160 and cancel; #X text 43 177 decay; #X text 284 272 on attack \, set a; #X text 278 305 recall sustain value; #X text 315 378 pack with decay time; #X text 605 332 on release ramp; #X text 606 349 back to zero; #X obj 462 329 * 0.01; #X text 47 567 Objects such as f and pack can be given dollar sign arguments to initialize their contents from adsr's creation arguments. Inlets are supplied to change them on the fly.; #X text 13 2 ADSR ENVELOPE; #X text 488 129 attack; #X text 555 128 decay; #X text 609 129 sustain; #X text 686 129 release; #X text 202 71 attack; #X obj 204 92 moses; #X obj 194 122 t b b; #X msg 128 290 0; #X text 20 273 optionally; #X text 10 291 bash to zero; #X text 25 246 ATTACK:; #X text 49 477 When you send this patch a positive trigger it schedules a line~ to do an attack and decay \, and if zero \, it starts the release ramp.; #X text 495 629 Updated for Pd version 0.37; #X text 255 89 test for negative trigger; #X text 253 113 if so \, zero; #X text 254 129 the output; #X text 278 165 in any case; #X text 303 355 multiply by peak level; #X text 280 286 delay for sustain; #X text 276 328 convert from percent; #X text 155 340 ... then; #X text 103 359 recall peak level; #X text 439 113 peak; #X text 281 149 ... do this; #X text 47 529 Negative triggers cause the output to jump to zero and then attack (instead of attacking from the current location).; #X text 208 1 Arguments: level \, attack time \, decay time \, sustain level \, release time. A \, D \, and R are in msec and S is in percent. This patch is used as an abstraction in various examples.; #X connect 0 0 3 0; #X connect 1 0 5 1; #X connect 1 0 18 1; #X connect 3 0 15 0; #X connect 3 0 16 0; #X connect 3 1 39 0; #X connect 4 0 5 0; #X connect 4 0 8 0; #X connect 5 0 6 0; #X connect 6 0 9 0; #X connect 7 0 6 1; #X connect 7 0 8 1; #X connect 8 0 10 0; #X connect 9 0
