Re: [PD] Object to store images and movies.
Javier Garcia wrote: Wellcome Donal, i think you are speaking about a to much complex aplication to be and object (at least nowadays). ??? an object can have arbitrary complexity. you could make a [linux] object, that runs a virtualized full operating system. however, the power of Pd is in _not_ having such blown-up object but a small, (more or less) orthogonal set of objects that allo you to build more complex objects. in this case: there is no high-level object that provides a media database; but you can build your own in Pd (if you wanted a single (external) object that does all for you, you would better search (or create) a specialized application and stay away from Pd for that very purpose). there are loads of ways to do the database, depending on your needs you can use file-system based storage of (media-)data, keep simple/numeric (meta-)data in tables, keep more complex data in textfiles, keep even more complex data in data-structures. all in all, you will have to keep your media-data (films, images) on your harddisk instead of a specilized object, and you will be glad about that once you have 30 gig of data and your RAM exploded You can construct that application with pd, but start from the begining with the doc. that is good advice fgmasdr. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] segmented patchcords (was Re: PD MAX)
hi lis this is a big discussion :) im a long term pd user, and no max user I vote YES for the segmented patchcords. i belive that it is not good to use them ALWAYS but i came i the situatuon when they come in handy and the user have a chance to choose... if you dont like them do not use them :-), if you need them, they are there. so i hope to see them soon in PD... greets, n On Dec 6, 2007 4:58 AM, Michal Seta [EMAIL PROTECTED] wrote: On Dec 4, 2007 10:09 AM, marius schebella [EMAIL PROTECTED] wrote: 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's not true. Ctl-click on a segmented patchcord, unsegments it. I found this shortcut by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 knees. Or something like that (my max demo expired a while ago). ./MiS ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.echoplex-label.de/njeremic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Object to store images and movies.
Donal Carey wrote: Hi Derek Thanks for the reply - to follow on from your info, can I create the database in PD or would I have to use some other program and then read from that using PD ? One way to accomplish that would be using [textfile]s: file no1. contains the file names of the textfiles that itself contains the files for [pix_texture], sth like: content of file1: slow; faster; fast; content of slow: slow_movie1; slow_movie2; ... [read file1( | [textfile] | [read $1] | [textfile] | [pix_film] | [pix_texture] | ... every time, the first [textfile] receives a bang, the next line is selected, the right outlet of [pix_film] gives a bang when the movie is finished, use that to bang the _2nd_ textfile, so that after slow_movie1, slow_movie2 is used. Read the help patches as well. cu Thomas -- Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance. (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Tue, 4 Dec 2007, Chris McCormick wrote: I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them? Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords. That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Object to store images and movies.
Oops, forgot: Thomas Mayer wrote: [read file1( | [textfile] | [read $1] | [textfile] | [open $1( | [pix_film] | [pix_texture] | -- Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance. (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Object to store images and movies.
As Thomas implicitly suggests, it is often easiest to arrange your clips with names and directories which your database (i.e. [textfile], [coll], the iem_matrix objects etc) can easily point to, such as: /home/donal/clips/slow/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov /home/donal/clips/bw/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov /home/donal/clips/red/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov etc etc etc The [sprintf] object is very powerful for making filenames with different directories and other variables, have a look at it! best, d. Thomas Mayer wrote: Oops, forgot: Thomas Mayer wrote: [read file1( | [textfile] | [read $1] | [textfile] | [open $1( | [pix_film] | [pix_texture] | -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 20: Be extravagant ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Object to store images and movies.
hi derek, thomas,, not sure, i havent read the whole thread but for clips and images lluis has some objects (i have to try but the suggested link is down and doesnt resolve for me since few weeks... though all is in CVS) there is a [videogrid] object gui that do exactly this. you can download it here http://artefacte.org/pd/; /a On Dec 6, 2007 12:03 PM, Derek Holzer [EMAIL PROTECTED] wrote: As Thomas implicitly suggests, it is often easiest to arrange your clips with names and directories which your database (i.e. [textfile], [coll], the iem_matrix objects etc) can easily point to, such as: /home/donal/clips/slow/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov /home/donal/clips/bw/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov /home/donal/clips/red/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov etc etc etc The [sprintf] object is very powerful for making filenames with different directories and other variables, have a look at it! best, d. Thomas Mayer wrote: Oops, forgot: Thomas Mayer wrote: [read file1( | [textfile] | [read $1] | [textfile] | [open $1( | [pix_film] | [pix_texture] | -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 20: Be extravagant ___ 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] segmented patchcords (was Re: PD MAX)
Le jeudi 06 décembre 2007 à 08:21 +0100, Frank Barknecht a écrit : Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Tue, 4 Dec 2007, Chris McCormick wrote: I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them? Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords. That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never. I am a PRO seg-cords as well although I dont miss it since [s/r $0-dingsbums] made my life easier. Moreover, the code has already been desired and written, just not been implemented in vanilla. Seg-cords + colored box/inlets + pdmtl +pdpedia give the opportunity to really expand the Pd user community, not only the Pd developers side. It took me a while to abandon (definetely I hope, unless the European Community cant resist the lobbying and forbids FLOSS) both traditional sequencers such as Logic (thanks to Pd) and OSes such as OSX (thanks to GNU/Linux), which i did mostly under political reasons (Fight the power :-). Still it would be great that people get _attracted_ to Pd for both its vast possibilities AND usability (including documentation), both low and high level programming prospects. Cheers! OH signature.asc Description: Ceci est une partie de message numériquement signée ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Object to store images and movies.
PDMTL has a growing number of features going into that direction too, as well as a preset storage system. It also has very pedagogic aspects :-) ++ O. Le jeudi 06 décembre 2007 à 12:03 +0100, Derek Holzer a écrit : As Thomas implicitly suggests, it is often easiest to arrange your clips with names and directories which your database (i.e. [textfile], [coll], the iem_matrix objects etc) can easily point to, such as: /home/donal/clips/slow/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov /home/donal/clips/bw/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov /home/donal/clips/red/ -clip1.mov -clip2.mov -clip3.mov -clip4.mov etc etc etc The [sprintf] object is very powerful for making filenames with different directories and other variables, have a look at it! best, d. Thomas Mayer wrote: Oops, forgot: Thomas Mayer wrote: [read file1( | [textfile] | [read $1] | [textfile] | [open $1( | [pix_film] | [pix_texture] | signature.asc Description: Ceci est une partie de message numériquement signée ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] making an Italian Version of pdpedia
Hello folks, I'm Fabio Buda and I study Electronic Music at Istituto Musicale V. Bellini of Catania (Sicily). I'd like to create an Italian Wiki of pdpedia: what can I do? Thanks Fabio [mbutUbuntu] Buda ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] oscSend, pd argument types
hey, i'm trying to use oscSend to send some numeric data to another application. basically i've got a float between 0 and 1. the receiving application unpacks the packet, assuming it's a float. the problem is, oscSend packs 0 and 1 as an int, but 0.01 - 0.999 as a float. so on the receiving end i have to check if the type is an int or a float and unpack it accordingly. i assume this is either caused by - the way pd passes around numbers internally, or - the way oscSend interprets incoming numbers. is there any simple workaround? -- damian stewart | +351 967 797 263 | [EMAIL PROTECTED] frey | live art with machines | http://www.frey.co.nz ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] VLC rc connection
I cc'ed the list since I think this is of general interest, also, other people can contribute there as well. On Dec 6, 2007, at 5:00 AM, wolfgang schwarzenbrunner wrote: The pdpedia can actually answer this question: http://wiki.puredata.info/en/Special:Search? search=tcpclientfulltext=Search :) .hc sorry...! found it... (well... not using the pd wiki but google ;) ) anyway i just found some sourcecodes on mr. peach´s website. i would definitely take in account to spend some time trying to compile it myself. still i ve never ever compiled anything myself (except from some old days when using debian... - but all of that knowledge got lost somewhere between 2002 and now) so just two little question: - i am on osx. should i try to compile it myself or will i run into s many inconveniences that it just would not work out? - whats a suitable compiler for osx (most common used?). will i be happy with xcode? i don`t really want to bother you with such generel questions. - just expect some hints. and i am not in hurry... so just write me back if there is time... It's included in Pd-extended as part of the 'mrpeach' library. .hc All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] oscSend, pd argument types
Damian Stewart wrote: hey, is there any simple workaround? yes, use mrpeach's [udpsend]+[packOSC] objects; they allow you use typed OSC-messages and whatelse. mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] oscSend, pd argument types
Damian Stewart wrote: hey, i'm trying to use oscSend to send some numeric data to another application. basically i've got a float between 0 and 1. the receiving application unpacks the packet, assuming it's a float. the problem is, oscSend packs 0 and 1 as an int, but 0.01 - 0.999 as a float. so on the receiving end i have to check if the type is an int or a float and unpack it accordingly. i assume this is either caused by - the way pd passes around numbers internally, or - the way oscSend interprets incoming numbers. is there any simple workaround? PD uses floats internally. oscSend tries makes ints out of floats which are equal to their integer representation A simple workaround is to add a tiny offset to the numbers and subtract it on the other end. I think it's better to use the mrpeach osc objects; you can force the type of the arguments of [packOSC] to be float. Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
On Dec 6, 2007, at 2:21 AM, Frank Barknecht wrote: Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Tue, 4 Dec 2007, Chris McCormick wrote: I think the key point to take from the whole discussion is that Max/MSP users have a choice, whilst under Pd we have no choice. It's all very well justifying how great it is to not have patch chords, but the lack of that feature/bug definately annoys some [potential] users and puts them off Pd. If the people want it, why not give it to them? Because it's easier to write a condescending justification for the lack of segmented patchcords than to write the code for segmented patchcords. That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never. But don't forget, anyone can become a developer, if they want! :D .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
I think some inlets take both, dsp and messages (throw~ for example). also, did you think about changing the look between edit and run mode? marius. Hans-Christoph Steiner wrote: On Dec 5, 2007, at 4:46 PM, Phil Stone wrote: Martin Peach wrote: Hans-Christoph Steiner wrote: Color really makes things stand out, especially in a black and white patch. So my question is, what would this color fade be communicating? A fade would stand out even more than a solid color, IMHO. What is that fade communicating and is it more important that other elements, like the object box, the inlets/outlets, the text in the boxes, etc. I guess just a quick way to tell which end is which. For instance the originating end could be redder and the terminating end could be bluer (and outlets would be red and inlets blue). Or colour saturation could decline along the cord. It may be more useful if a mouseover made the colours appear, otherwise everything stays black. Martin I don't know what made me think of this from reading your post, Martin, but it suddenly occurred to me that a good use for color would be red (or orange, or yellow... ) for hot inputs to objects. I'm not sure if it could be practically implemented without modifying the object's source, though. While for 99% of objects, it would be the left inlet, in the exceptional cases like [timer], the visual reminder would be particularly valuable. That is a nice idea, it would be good to have on the GUI Ideas wiki page: http://puredata.info/dev/GuiIdeas I've been playing with a color a bit in Pd-extended recently, I think a little bit of color used judiciously can definitely make things more readable. Here are two examples of where I think it helps (check the inlets/outlets and the error box): The audio inlets are colored and solid, the message inlets are black/white box. .hc Phil Stone pkstonemusic.com ___ 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 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
Yes, definitely, I am thinking of something that combines the two, like a black box with blue inside. I am going to play with that more. The problem is that it's trickier to program that, hopefully it's not too tricky. .hc On Dec 6, 2007, at 10:48 AM, marius schebella wrote: I think some inlets take both, dsp and messages (throw~ for example). also, did you think about changing the look between edit and run mode? marius. Hans-Christoph Steiner wrote: On Dec 5, 2007, at 4:46 PM, Phil Stone wrote: Martin Peach wrote: Hans-Christoph Steiner wrote: Color really makes things stand out, especially in a black and white patch. So my question is, what would this color fade be communicating? A fade would stand out even more than a solid color, IMHO. What is that fade communicating and is it more important that other elements, like the object box, the inlets/outlets, the text in the boxes, etc. I guess just a quick way to tell which end is which. For instance the originating end could be redder and the terminating end could be bluer (and outlets would be red and inlets blue). Or colour saturation could decline along the cord. It may be more useful if a mouseover made the colours appear, otherwise everything stays black. Martin I don't know what made me think of this from reading your post, Martin, but it suddenly occurred to me that a good use for color would be red (or orange, or yellow... ) for hot inputs to objects. I'm not sure if it could be practically implemented without modifying the object's source, though. While for 99% of objects, it would be the left inlet, in the exceptional cases like [timer], the visual reminder would be particularly valuable. That is a nice idea, it would be good to have on the GUI Ideas wiki page: http://puredata.info/dev/GuiIdeas I've been playing with a color a bit in Pd-extended recently, I think a little bit of color used judiciously can definitely make things more readable. Here are two examples of where I think it helps (check the inlets/outlets and the error box): - --- The audio inlets are colored and solid, the message inlets are black/white box. .hc Phil Stone pkstonemusic.com ___ 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 - --- 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 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] segmented patchcords (was Re: PD MAX)
Michal Seta wrote: On Dec 4, 2007 10:09 AM, marius schebella [EMAIL PROTECTED] wrote: 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's not true. Ctl-click on a segmented patchcord, unsegments it. I found this shortcut by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 knees. Or something like that (my max demo expired a while ago). not on my machine with my max version :( marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] making an Italian Version of pdpedia
Just ask! :D I made the IT wiki, now create an account in it, and post your username here. Then I can make it admin: http://pdpedia.org/ I don't know if you have any contact with this group, but it looks like it would be good to get them to help too: http://puredata.bugslab.net/ http://www.digicult.it/digimag/article.asp?id=901 .hc On Dec 6, 2007, at 7:43 AM, Fabio Buda [mbutUbuntu] wrote: Hello folks, I'm Fabio Buda and I study Electronic Music at Istituto Musicale V. Bellini of Catania (Sicily). I'd like to create an Italian Wiki of pdpedia: what can I do? Thanks Fabio [mbutUbuntu] Buda ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
On Dec 5, 2007, at 12:45 PM, B. Bogart wrote: Ah segmented patch coords again. How about a real solution to the problem of routing objects in diagrams? In PD this could mean a few things: 1. Best patching practise!!! Often you can choose not to overlap objects and connections just by arranging objects as the connections force you to, which gives you the valuable side-effect of having the position of object show the flow of the patch more clearly. 2. Empirical tests have shown that curved (spline) connections between nodes are actually the best way to make them easier to follow, so yay for spline/curved connections and nay for segments! (See p193, figure 6.8 in Information Visualization: Perception for Design by Colin Ware.) This is the kind of stuff I am trying to get at. I think that there is a lot that we can do with Pd to make it feel a lot more natural. I really want to get into how humans are wired to perceive the world, and try to reuse some of that existing circuitry to communicate aspects of Pd on a really low level, like unconscious. For example, you don't need to think about it to know that you see something moving. You can actually get substantial amount of data about a moving object without even being conscious that you paying attention to it. There is a ton of circuitry in the brain that is constantly processing the input from all of the senses, and only a minute fraction of that information is ever brought forth to your conscious mind. The key part is that you are not ignoring that data, but processing it in the background. You don't need to be consciously listening to all sounds to hear your name being called. I'm going to get that book from the library now, if anyone else knows some good materials on applying knowledge of persception to design, please let me know! I haven't found many good resources. Lots of ideas and attempts, but very few clear concepts or even examples. .hc 3. I noticed the new inkscape has some very fancy graph drawing features, one of which is the ability to tell connections to automatically route around nodes. They are not curved, but the idea of a PD where connections simply avoid objects themselves has a lot of potential. Of course I'm not saying adding the choice is necessarily a bad thing, but the real question is what nurtures best practise? That remains to be seen, but I'd be very surprised if segmented connections were it. .b. marius schebella wrote: 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. ___ 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 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] Max Pd
Hi Andrew, I use both. I am in a graduate class at brooklyn polytech, where josh goldberg teaches real time video interaction. it is an advanced class, and there are only 6 people, 3 of them are passionate (professional?) jitter users, and 2 people started using max in this program, but are also using other real time programs (or write their own C/Java/whatever code) plus me. It is not a dedicated max class, but max gets the greatest support. I really tried hard to stay with Pd and do everything in GEM+... but at some point this year I realized that GEM is not at all that highly developed as max and jitter. the most obvious and useful things are the tons of @arguments that each objects accepts. then, with pwindow you always have small control windows inside your patch. all textures can be referenced by giving a @name attribute. you can switch easily between matrix computation and gl world. you have better scripting support, plus more addons. the problem with gem, as I mentioned already on the list, is that it does not have enough developers. only iohannes and chris clepper are working on it, and it is more maintenance, than active developing. myself I am trying hard to get into GEM development, but it takes time until I know enough to be able to do that. the limitations of GEM at the moment are: no real multitexture support for opengl. that is a must, if you want to work with shader languages like glsl. (jitter has that plus also javascript to combine the shaders, which in pd you have to do by patching.) this should be easily fixed by someone with sufficiant knowledge of the opengl world and gem (and time and resources...). wesley, who is also on this list, but also developing for c74, wrote the lua objects for jitter, and pdlua should be able to do equivalent stuff on pd-side for that (I am working to get it included into pd-extended.) I could imagine that luagl people would rather use pd than max, because of open source. on osx 10.5 the GEM window doesnot come to the front and does not accept mouseclicks. I experienced problems with the colorspace on osx with some pix_obects. on the other side jitter comes with a huge set of externals and abstractions. cv.jit is a great additional resource. but there are tons... jitter has the more lively user community and you have more developers. both programs lack of good vector graphics handling objects (like flash). this is a big lack in the open source world. a web savy open source replacement for flash!!! still, my heart beats for the open source community, so I would like to see gem and pd do the same things (and more) than max and jitter can do. If you work in longtime installations you want to use linux and gem. opengl/gem on linux is faster than anything else (well at least faster than max/jitter). os x graphics drivers even limit some features of the gfx card for compatibility reasons... for the next 3 years at least, gem will be behind, and if there are no new coders that will not change. I am not sure if this will change without money getting involved. the only other possibility to get people involved is teaching pd/gem at college level. and get student programmers involved. or grab some money for gem development. google summer of code, or grants... above all that, there are all still the obvious pro/cons of max vs pd. marius. Andrew Brouse wrote: Hello Pd and Max folks, I am doing a presentation (tomorrow!... so this request is a bit late!) on differences between Max and Pd as tools for music and media art. I am interested in hearing: 1. from people who actively use both 2. about less-obvious advantages/disadvantages of one or the other 3. specifically about functionality for manipulation of video, OpenGL including shaders and matricial data 4. clear, reasoned, articulate thoughts and arguments as to why one or the other is better or worse for one or another particular use ( why should I expect anything else! ;) This could have some impact on decisions which will be made for a project which I can't talk about yet. :) thanks for your help, Andrew ___ 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] Max Pd
marius schebella wrote: only iohannes and chris clepper are working on it and that means thank you very much! I am not sure how to really support the work you are doing? if you ever come up with a wishlist... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
oh! it depends WHERE you click. thanks! marius. vade wrote: you have to command click on OS X - it works, and on patch coords with only one knee too. (select the half towards the inlet). On Dec 6, 2007, at 10:48 AM, marius schebella wrote: Michal Seta wrote: On Dec 4, 2007 10:09 AM, marius schebella [EMAIL PROTECTED] wrote: 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's not true. Ctl-click on a segmented patchcord, unsegments it. I found this shortcut by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 knees. Or something like that (my max demo expired a while ago). not on my machine with my max version :( 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] segmented patchcords (was Re: PD MAX)
you have to command click on OS X - it works, and on patch coords with only one knee too. (select the half towards the inlet). On Dec 6, 2007, at 10:48 AM, marius schebella wrote: Michal Seta wrote: On Dec 4, 2007 10:09 AM, marius schebella [EMAIL PROTECTED] wrote: 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's not true. Ctl-click on a segmented patchcord, unsegments it. I found this shortcut by mistake once. Caveat, it does not work on all segemented patchcords. IIRC it works if the patchcord has a minimum of 2 knees. Or something like that (my max demo expired a while ago). not on my machine with my max version :( 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] segmented patchcords (was Re: PD MAX)
In reactable, objects are connected together when inlet/outlet matches the good kind of data, it would be possible to do it also with PureData, without breaking the rules. If a box is dragged nearly another box, the connection would happen when an inlet/outlet passes into the area of another inlet/outlet. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Pd
On Thu, 6 Dec 2007, marius schebella wrote: the most obvious and useful things are the tons of @arguments that each objects accepts. Having tons of @arguments is not necessarily a blessing. Wherever Jitter has four @arguments named red,green,blue,alpha, GridFlow has only one, which is a list of the four colour components after a [#pack]. It makes GridFlow more structured than Jitter in this case, and that makes some objects more open to different colour spaces than Jitter's, in addition to yielding a better [EMAIL PROTECTED] ratio. _ _ __ ___ _ _ _ ... | 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] Max Pd
Nicely said, hopefully you can drum up more support for Gem. One thing I think it really great about Gem is that is remains strongly visual. When getting heavy into jitter, the patches look like you are writing in C++ with boxes around it. What I would really like to see is all those naming and attribute features represented in a visual way, rather than just long lines of text like in Jitter. THen if you want to write text-based code, you can use luagl, etc. There are a lot of hidden secrets in Gem, you can do a lot with it. For example, you can use all of the OpenGL primitives, check out Help- Browser-examples-Gem-09.opengGL Just having better docs and more examples would go a long way. And I agree, Chris and IOhannes have been doing great work for a long time, and I don't think it's properly recognized. .hc On Dec 6, 2007, at 11:46 AM, marius schebella wrote: Hi Andrew, I use both. I am in a graduate class at brooklyn polytech, where josh goldberg teaches real time video interaction. it is an advanced class, and there are only 6 people, 3 of them are passionate (professional?) jitter users, and 2 people started using max in this program, but are also using other real time programs (or write their own C/Java/ whatever code) plus me. It is not a dedicated max class, but max gets the greatest support. I really tried hard to stay with Pd and do everything in GEM+... but at some point this year I realized that GEM is not at all that highly developed as max and jitter. the most obvious and useful things are the tons of @arguments that each objects accepts. then, with pwindow you always have small control windows inside your patch. all textures can be referenced by giving a @name attribute. you can switch easily between matrix computation and gl world. you have better scripting support, plus more addons. the problem with gem, as I mentioned already on the list, is that it does not have enough developers. only iohannes and chris clepper are working on it, and it is more maintenance, than active developing. myself I am trying hard to get into GEM development, but it takes time until I know enough to be able to do that. the limitations of GEM at the moment are: no real multitexture support for opengl. that is a must, if you want to work with shader languages like glsl. (jitter has that plus also javascript to combine the shaders, which in pd you have to do by patching.) this should be easily fixed by someone with sufficiant knowledge of the opengl world and gem (and time and resources...). wesley, who is also on this list, but also developing for c74, wrote the lua objects for jitter, and pdlua should be able to do equivalent stuff on pd-side for that (I am working to get it included into pd-extended.) I could imagine that luagl people would rather use pd than max, because of open source. on osx 10.5 the GEM window doesnot come to the front and does not accept mouseclicks. I experienced problems with the colorspace on osx with some pix_obects. on the other side jitter comes with a huge set of externals and abstractions. cv.jit is a great additional resource. but there are tons... jitter has the more lively user community and you have more developers. both programs lack of good vector graphics handling objects (like flash). this is a big lack in the open source world. a web savy open source replacement for flash!!! still, my heart beats for the open source community, so I would like to see gem and pd do the same things (and more) than max and jitter can do. If you work in longtime installations you want to use linux and gem. opengl/gem on linux is faster than anything else (well at least faster than max/jitter). os x graphics drivers even limit some features of the gfx card for compatibility reasons... for the next 3 years at least, gem will be behind, and if there are no new coders that will not change. I am not sure if this will change without money getting involved. the only other possibility to get people involved is teaching pd/gem at college level. and get student programmers involved. or grab some money for gem development. google summer of code, or grants... above all that, there are all still the obvious pro/cons of max vs pd. marius. Andrew Brouse wrote: Hello Pd and Max folks, I am doing a presentation (tomorrow!... so this request is a bit late!) on differences between Max and Pd as tools for music and media art. I am interested in hearing: 1. from people who actively use both 2. about less-obvious advantages/disadvantages of one or the other 3. specifically about functionality for manipulation of video, OpenGL including shaders and matricial data 4. clear, reasoned, articulate thoughts and arguments as to why one or the other is better or worse for one or another particular use ( why should I expect anything else! ;) This could
Re: [PD] Max Pd
well, FYI in Jitter you do [jit.someobject @color r g b a] (for example), or can use a message named color. Ive never seen or used [jit.someobject @red r @green g @blue b @alpha a] and jitter also has just about every colorspace conversion possible, that I have ever seen or dealt with professionally, and many I have not heard of or ever had to use: http://cycling74.com/documentation/jit.colorspace Not meant as flame bait (sorry, I still feel like an ass for yesterday Mathieu!), but more for compare/contrast. I quite like the attribute system jitter has, and think it could be imported with some sort of syntax highlighting for objects where attribute names are one color and their set values another. It would (may?) help visually grokking the text within the patcher object On Dec 6, 2007, at 2:16 PM, Mathieu Bouchard wrote: On Thu, 6 Dec 2007, marius schebella wrote: the most obvious and useful things are the tons of @arguments that each objects accepts. Having tons of @arguments is not necessarily a blessing. Wherever Jitter has four @arguments named red,green,blue,alpha, GridFlow has only one, which is a list of the four colour components after a [#pack]. It makes GridFlow more structured than Jitter in this case, and that makes some objects more open to different colour spaces than Jitter's, in addition to yielding a better features-per- @arguments ratio. _ _ __ ___ _ _ _ ... | 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
i read your mail as a pledge for a bounty system - is that right? Am 06.12.2007 um 20:08 schrieb Kyle Klipowicz: And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached. There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape). I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C. After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true. Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the serious tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case... No flames meant in this mail, just compassionate thought-mulling. ~Kyle On Dec 6, 2007 1:21 AM, Frank Barknecht [EMAIL PROTECTED] wrote: That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never. -- - - - -- http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz ___ 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] Max Pd
You can do both within jitter, anything that is an attribute is by virtue of being an attribute also a message - so you can send it via loadbang, loadmess or whenever/however you want, so its up to you to choose how you want your patch to work :) On Dec 6, 2007, at 2:16 PM, Hans-Christoph Steiner wrote: icely said, hopefully you can drum up more support for Gem. One thing I think it really great about Gem is that is remains strongly visual. When getting heavy into jitter, the patches look like you are writing in C++ with boxes around it. What I would really like to see is all those naming and attribute features represented in a visual way, rather than just long lines of text like in Jitter. THen if you want to write text-based code, you can use luagl, etc. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
Now there's an idea! If some donations could be had to offer up bounty money, I'd say a few more of us would be inclined to pitch in. Also, has pd been in the Goggle Summer of Code? ... I'm unfamiliar with the dev setup but have there been any coding camps where people get together to just implement something, just do it for like a weekend? It is always nice to tackle a problem with someone to bounce ideas off of in person. Couchsurfing.com, an online lend-your-couch travel networking collective, has a week long code session every 6 months I believe. Of course the participants get a free place to stay, etc but I don't see how something like that couldn't be sponsored for pd. Personally, I'd like to jump into some pd dev but I am no so sure where to start where it would be most effective (other then segmented patch cords :P). i read your mail as a pledge for a bounty system - is that right? Am 06.12.2007 um 20:08 schrieb Kyle Klipowicz: And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached. There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape). I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C. After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true. Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the serious tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case... No flames meant in this mail, just compassionate thought-mulling. ~Kyle On Dec 6, 2007 1:21 AM, Frank Barknecht [EMAIL PROTECTED] wrote: That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until someone comes along who wants seg-cords in Pd and at the same time could write the code, the feature stays missing. That's not unusual wiht open source software: features, the developers need, get implemented faster, others maybe never. -- - - - -- http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list -- Dan Wilcox danomatika www.robotcowboy.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Pd
On Thu, 6 Dec 2007, vade wrote: well, FYI in Jitter you do [jit.someobject @color r g b a] (for example), or can use a message named color. Ive never seen or used [jit.someobject @red r @green g @blue b @alpha a] I forgot to say that it applies only to some of the classes in Jitter. For example: http://cycling74.com/documentation/jit.eclipse I haven't looked at how many classes do it like that for the colours, but also some classes treat x and y axes as separate attributes instead of together, for example. I quite like the attribute system jitter has, and think it could be imported with some sort of syntax highlighting for objects where attribute names are one color and their set values another. So far I'm ok with the attribute system of GridFlow; Flext users seem ok with the attribute system of Flext; and the syntax is already mostly enough: the comma of GridFlow and the at-sign of Flext are distinctive enough. Colouring is not much of an addition because the text-based syntax of pd/max is too simple for that. (pd/max's syntax is more patch-based than text-based). It would (may?) help visually grokking the text within the patcher object grok should be reserved for what it originally meant, which is more intense than understanding how it works, let alone being able to parse the text. I'd love it if just the colours were enough to communicate the totality of the meaning of pd :} but it's not going to happen. _ _ __ ___ _ _ _ ... | 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] segmented patchcords (was Re: PD MAX)
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote: And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached. There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape). Ubuntu, while open source, is a commercial product. Like Redhat Linux and many other commercial FLOSS products. For these kinds of open source software, money of course is one motivation, and if that money comes directly from the user, the user's wishes are a influencing the software more directly. Money is not a bad motivator, and it's even playing a role in our little Pd world, where some projects are or have been funded (like IIRC the early work by Hans on pd-extended, or many docs, which were made for paid workshops etc.) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
If I were running a commercial software firm and software made by random people in their spare time compared pretty well with my pricey software, I would be a little concerned. On Dec 6, 2007 1:08 PM, Kyle Klipowicz [EMAIL PROTECTED] wrote: And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached. There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape). I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C. After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true. Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the serious tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case... No flames meant in this mail, just compassionate thought-mulling. ~Kyle ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Meaning of -noprefs
Hi, I think -noprefs should stop .pdrc as well, since it's in the spirit that is great news! Btw, is there a document on the available options in .pdsettings? For example: Does defeatrt: 0 imply -rt? Otherwise, how does one set -rt? Which Audio-API is which number? Let me take the opportunity to address two other issues, both already discussed a lot on the list but still worthy to address: Hiding hidden folders in Tcl's file dialog. (1) The position of objects being pasted into a patcher. (2) After almost five years of working with pd a lot, these two things are the ones, that bother users (like me) the most. They might be hard to solve, but are still necessary to solve. One can live without much eye-candy and other 'nice-to-have' features very well. But those two things are an obstacle to everyday work in pd, because (1) is slowing the work down, and (2) is causing confusion. thanks regards from Peter * Miller Puckette [EMAIL PROTECTED] [2007-12-05 23:46]: Hi all, I think -noprefs should stop .pdrc as well, since it's in the spirit of being able to find out whether a problem is coming from the configuration or from Pd itself. If it's reasonably easy to do I'll change that. That said, I think .pdrc should be regarded as deprecated, unless there's something you can do with it that can't be done in .pdsettings instead. cheers Miller On Wed, Dec 05, 2007 at 09:31:31AM +0100, Peter Plessas wrote: Dear List, Simon Thanks Simon for your kind reply and explanations So although there might be space for calling that behavior an additional but questionable 'feature', i consider it an inconsistency in user interface design. Preferences are preferences, whether they are in a .pdrc file or in a preferences file. IMHO -noprefs should disable all preferences-mechanisms. Regards, Peter simon wise wrote: On 1 Dec 2007, at 10:11 PM, Peter Plessas wrote: i thought that the -noprefs flag also disables loading of the .pdrc file on linux, but it does not. Is this intentional on 0.40-2? Since the preference dialogues were added they have always been treated as quite separate from the older .pdrc system - IMHO this split remains useful as it is possible to either ignore the older system (just delete any .pdrc files) or use it instead (delete the settings files instead) or use both in parallel to help manage your settings in different ways for different circumstances (eg using the .pdrc to set up machine specific things like which soundcard to use while selecting libraries and startup patches with the preferences). The newer preference system is getting some very useful features - especially the embedded option! - and when the dialogue box eventually gets more than 10 slots I will use the .pdrc system less often. simon ___ 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] Object to store images and movies.
Thanks for all the info guys - will post the patch up if I get it working. Cheers Donal ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] italian infobox
hello folks, I've just translated the Firts Page of the italian wiki... here there is the IT translation of infobox # wikipedia terms $stub = matrice; $template = modello; $category = categoria; $infobox = casella informativa; # pdpedia terms $objectclass = classe di oggetti; # page headers $inlets = ingressi; $outlets = uscite; $arguments = argomenti; $messages = messaggi; # infobox $name = nome; $description = descrizione; $abbreviation = abbreviazione; $example image = immagine d'esempio; $caption = didascalia; $library = libreria; $author = autore; $developer = sviluppatore; $releaseVersion = versione di rilascio; $releaseDate = data di rilascio; $status = stato; $dependencies = dipendenze; $license = licenza; $website = sito web; $programmingLanguage = linguaggio di programmazione; $platform = piattaforma; $operatingSystem = sistema operativo; $language = lingua; $dataType = tipo di dati; $distribution = distribuzione; # proposed additions $helppatch name = ; $cpu use index = indice di utilizzo della cpu; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Object to store images and movies.
On 12/5/07, Derek Holzer [EMAIL PROTECTED] wrote: If you are using GEM, then look at [pix_image], [pix_film] and [pix_movie]. You'll need to develop some sort of rudimentary database to catalog and access the images and clips, of course... As far as the Database stuff goes, if you would like, please check out the SQLite external. It is posted on the Pure Data website at ( http://puredata.info/Members/mjmogo ). While it is still under developement, it is quite usable. It still doesn't have support for storing Blob kinds of data, but this would be a good time to discuss adding those features. (Sorry to go off topic, but this might be something that helps to change what I see as a lack in PD. A coherent, simple means of storing and retrieving data.) Mike ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD MAX))
Yes, a bounty system would be great. At this point, if you are not a student, Max/MSP/Jitter costs about $850 US. I think that (myself included) many Pd users would gladly shell out a few dollars to see features met. I for one have donated to Hans' efforts directly on his site via PayPal, because I know of the importance of financial 'reinforcement.' What is Matju's bounty on getting gridflow working out of box on OS X? ~Kyle On Dec 6, 2007 2:05 PM, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote: And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached. There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape). Ubuntu, while open source, is a commercial product. Like Redhat Linux and many other commercial FLOSS products. For these kinds of open source software, money of course is one motivation, and if that money comes directly from the user, the user's wishes are a influencing the software more directly. Money is not a bad motivator, and it's even playing a role in our little Pd world, where some projects are or have been funded (like IIRC the early work by Hans on pd-extended, or many docs, which were made for paid workshops etc.) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Pd
I also think that megaobjects that accept many messages/attributes become more like application preferences rather than programming, and that usually limits the possibilities. For example, in C, a function with more than 5 parameters starts to get quite ugly and unwieldy. In LISP, which Max's list handling is modeled after, it is also not good form to have many attributes in a single function. Objectclasses in object-oriented languages like Java, etc. accept many messages, but I think that Max is more like a functional language than an object-oriented one, (but somewhere in between). I'm not saying I have the answer (yet? :) but this for me, thinking about these kinds of things makes for a more intuitive and fluid programming language. (and when I say Max here, I am talking Max family, which includes Pd). .hc On Dec 6, 2007, at 2:38 PM, vade wrote: You can do both within jitter, anything that is an attribute is by virtue of being an attribute also a message - so you can send it via loadbang, loadmess or whenever/however you want, so its up to you to choose how you want your patch to work :) On Dec 6, 2007, at 2:16 PM, Hans-Christoph Steiner wrote: icely said, hopefully you can drum up more support for Gem. One thing I think it really great about Gem is that is remains strongly visual. When getting heavy into jitter, the patches look like you are writing in C++ with boxes around it. What I would really like to see is all those naming and attribute features represented in a visual way, rather than just long lines of text like in Jitter. THen if you want to write text-based code, you can use luagl, etc. All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
On Thu, 6 Dec 2007, Olivier Heinry wrote: Moreover, the code has already been desired and written, just not been implemented in vanilla. excuse me, which version of pd really allows you to edit and save cord segmentations? _ _ __ ___ _ _ _ ... | 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] Max Pd
On Dec 6, 2007 10:46 AM, marius schebella [EMAIL PROTECTED] wrote: no real multitexture support for opengl. that is a must, if you want to work with shader languages like glsl. Multitexturing works fine. The only drawback is that only texcoords from the texture unit in the chain with the shader can be used. This only presents a problem if the texture dimensions are different sizes. this should be easily fixed by someone with sufficiant knowledge of the opengl world and gem (and time and resources...). Unfortunately it is either not easy to fix or just beyond my abilities to do so. I have spent many, many hours trying to get this to work but cannot make it so. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Pd
This is an interesting viewpoint - at what point does providing all of these options just get in my way and make me not think about creating my own solutions - and thus really really making it mine - while extending my knowledge Im not sure, I can tell you ive had to make plenty of my own solutions with Max/Jitter - but I think you have a very valid point. There certainly are a few assumptions on Jitters part that I do not necessarily agree with. Well said. On Dec 6, 2007, at 4:10 PM, Hans-Christoph Steiner wrote: I also think that megaobjects that accept many messages/attributes become more like application preferences rather than programming, and that usually limits the possibilities. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD MAX))
Kyle Klipowicz wrote: I for one have donated to Hans' efforts directly on his site via PayPal, now it's out, YOU were the one... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd 0.41.0 test07 font size
hello, yes, test 09 look good. whatever the screen resolution is. (at least on my ubuntu computer) thanks Cyrille Miller Puckette a écrit : OK test09, hopefully, fixes it :) I've got a long list of bugs to try to fix... otherwise I'm probably not going to try to add any more features to this release before canning it. cheers Miller On Fri, Nov 23, 2007 at 07:04:25PM +0100, cyrille henry wrote: hello, test 08 is better, but not perfect : - the font of the objects are the same whatever the screen size - ok - the font size of text in the main pd window is still change - the font size of the comment (canvas label) that i use in the _gemwin gop abstraction are also changing. should i upload new snapshot? thanks, Cyrille ___ 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] Max Pd
I have no idea how complicated this stuff really is. from the user's viewpoint it looked like some lines of code, that needed to be added. and I know that it is even harder if you are alone in your problem solving... marius. chris clepper wrote: On Dec 6, 2007 10:46 AM, marius schebella [EMAIL PROTECTED] wrote: no real multitexture support for opengl. that is a must, if you want to work with shader languages like glsl. Multitexturing works fine. The only drawback is that only texcoords from the texture unit in the chain with the shader can be used. This only presents a problem if the texture dimensions are different sizes. this should be easily fixed by someone with sufficiant knowledge of the opengl world and gem (and time and resources...). Unfortunately it is either not easy to fix or just beyond my abilities to do so. I have spent many, many hours trying to get this to work but cannot make it so. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd 0.41.0 test07 font size
Miller Puckette wrote: Well, not much has happened, but the test version is stable enough it seems better to work toward a stable version of teh present state than to try to add all the features I want to put in next :) that sounds even better! i'll get my wishlist engine running before soon with stuff like: - user defined atom-types - a better saving hook including - somehow moving open abstraction into sys_loadlib chain - 64bit-pd (that is, not just run pd on an amd64; but have t_float/t_sample be *large*) - .. - and all rest i cannot think of right now fg,adf IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd 0.41.0 test07 font size
Miller Puckette wrote: OK test09, hopefully, fixes it :) I've got a long list of bugs to try to fix... otherwise I'm probably not going to try to add any more features to this release before canning it. i have jut assigned you some more patches in the patchtracker at sourceforge...;-) so this basically means that we will get a new pd-version soon? great! fmfadt. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd 0.41.0 test07 font size
Well, not much has happened, but the test version is stable enough it seems better to work toward a stable version of teh present state than to try to add all the features I want to put in next :) M On Fri, Dec 07, 2007 at 01:17:19AM +0100, IOhannes m zmoelnig wrote: Miller Puckette wrote: OK test09, hopefully, fixes it :) I've got a long list of bugs to try to fix... otherwise I'm probably not going to try to add any more features to this release before canning it. i have jut assigned you some more patches in the patchtracker at sourceforge...;-) so this basically means that we will get a new pd-version soon? great! fmfadt. IOhannes ___ 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] pd and max (2)
oh, forgot find last error, even if this does not work all the time, it really helped me save a lot of time. plus find feature is also not implemented in max. marius. marius schebella wrote: 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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD MAX))
hey... On Dec 6, 2007 5:50 PM, marius schebella [EMAIL PROTECTED] wrote: Kyle Klipowicz wrote: I for one have donated to Hans' efforts directly on his site via PayPal, now it's out, YOU were the one... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.sideshowmedia.ca skype: chickeninthegrass ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
On Thu, Dec 06, 2007 at 04:24:42PM -0500, Mathieu Bouchard wrote: On Thu, 6 Dec 2007, Olivier Heinry wrote: Moreover, the code has already been desired and written, just not been implemented in vanilla. excuse me, which version of pd really allows you to edit and save cord segmentations? Hi Matju, Didn't I once see screenshots from you of patches that showed segmented and spline curve patch chords? Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD MAX))
Le 6 déc. 07 à 22:05, Kyle Klipowicz a écrit : Yes, a bounty system would be great. At this point, if you are not a student, Max/MSP/Jitter costs about $850 US. I think that (myself included) many Pd users would gladly shell out a few dollars to see features met. I for one have donated to Hans' efforts directly on his site via PayPal, because I know of the importance of financial 'reinforcement.' What is Matju's bounty on getting gridflow working out of box on OS X? It would be nice to have this library directly in pd-extended ! ;) Or a great tutorial (How to install gridflow on osx for beginner ?) Jack ~Kyle On Dec 6, 2007 2:05 PM, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote: And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached. There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape). Ubuntu, while open source, is a commercial product. Like Redhat Linux and many other commercial FLOSS products. For these kinds of open source software, money of course is one motivation, and if that money comes directly from the user, the user's wishes are a influencing the software more directly. Money is not a bad motivator, and it's even playing a role in our little Pd world, where some projects are or have been funded (like IIRC the early work by Hans on pd-extended, or many docs, which were made for paid workshops etc.) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz ___ 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] pd and max (2)
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd and max (2)
On Thu, Dec 06, 2007 at 07:45:41PM -0500, marius schebella wrote: * 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. In fact, Pd has such a free license that you can even fork it and make your own closed-source commercial product out of it if you want. The only requirement is that you include the license and copyright. Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] freeverb~ roomsize / damping not working
hi, i compiled freeverb~ without any problem, but the controls are not modifying the sound. a theora video of the problem can be seen here: http://www.workinprogress.ca/pd/pdmtl/freeverbbug.ogg (vlc, mplayer etc...). i am on linux / pentium 4. freeverb~ v1.2 pat ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd 0.41.0 test07 font size
On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote: i'll get my wishlist engine running before soon with stuff like: - 64bit-pd (that is, not just run pd on an amd64; but have t_float/t_sample be *large*) does that mean, that every float in pd on an 64bit machine will have 64bit precision? and each sample in a table uses 8 byte ram? does it also mean, that there will be less [tabread4~] floating point rounding issues (in other words: [tabread4~] sounds 'good' up to x minutes?) 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] segmented patchcords (was Re: PD MAX)
On Dec 6, 2007, at 2:54 PM, Daniel Wilcox wrote: Now there's an idea! If some donations could be had to offer up bounty money, I'd say a few more of us would be inclined to pitch in. Patches welcome! ;) Seriously, if anyone wants to set this up, I think it could work. In the past, some people objected to the idea since they didn't think it's fair (check the archives). I think it could be done fair if people are directly sponsored the work they wanted done. Maybe there is a site that provides this service already? Sourceforge has started something like that, but I don't know the details. Also, has pd been in the Goggle Summer of Code? Yup, there were two funded projects last summer. The number of funded slots that google provides is directly related to how many project submissions there are, so next summer, we should really work together to make sure there are lots of submissions. I mean we can actually help write the applications together on the list. ... I'm unfamiliar with the dev setup but have there been any coding camps where people get together to just implement something, just do it for like a weekend? It is always nice to tackle a problem with someone to bounce ideas off of in person. Couchsurfing.com, an online lend-your-couch travel networking collective, has a week long code session every 6 months I believe. Of course the participants get a free place to stay, etc but I don't see how something like that couldn't be sponsored for pd. I think a coding camp is an awesome idea, I would love that! The problem for me is that there are few Pd people in the NYC area. Or at least not so many who come to the patching circles that we run about every month or so. If there was a way to bring more people to the patching circles, I am willing to make the effort. For example, I can host people at my house. Come January, I'll have a pull out bed, a mattress in the office, and even an inflatable mattress also. In addition, if it is during the early summer, I think I could organize rooms at the Polytechnic dorm for $40 a night, which is very cheap for NYC (the youth hostels are more). Personally, I'd like to jump into some pd dev but I am no so sure where to start where it would be most effective (other then segmented patch cords :P). I think it's best to work on something that you are interested in, but I'll happily make suggestions if you want. :-) .hc i read your mail as a pledge for a bounty system - is that right? Am 06.12.2007 um 20:08 schrieb Kyle Klipowicz: And this is precisely the unfortunate reason why the open source world will (almost) always lag behind the commercial world of consumer software. When developers make their bread and butter based upon if the consumer buys, they're more likely to pay attention to and implement the wishes of their users. Take Ableton. They actively parse their online forums for feature requests...and then implement them when a critical mass is reached. There are some exceptions in the FOSS world. Ubuntu is quite user friendly (with the support of a large endowment from a very wealthy organization with a charter specifically devoted to bringing Linux to the non-programmer set of the world). Firefox is giving IE a run for it's money (although the primary codebase from FF comes from the old commercial, closed source Netscape). I know that Hans' statement re everyone becoming a developer is true in theory, but in reality people who want to rapidly prototype a project with something like Pd or Max are using these applications precisely because they do not want to code in C. After reading Marius' post re GEM vs. Jitter, it is painfully apparent that the capitalist/consumer model of software engineering has a few aspects to it that are difficult for the FOSS community to compete with. Namely monetary and human resources and the external pressure to meet the requests of the user in order to ensure a continuous flow of financial support. When you code for a hobby or yourself, it is difficult or even impossible to be bothered with these things, and rightly so. Without compensation, there's often little scope (or time) outside one's own projects for developers in the FOSS world. This is unfortunate, but as I see it, true. Question is, what can be done to change this or compete? Or should Pd just become the thing that hobbyist programmers use, while Max takes the stage as the serious tool for rapidly prototyping interactive A/V artworks? I hope that this is not the case... No flames meant in this mail, just compassionate thought-mulling. ~Kyle On Dec 6, 2007 1:21 AM, Frank Barknecht [EMAIL PROTECTED] wrote: That's exactly the point: From this thread it seems that many of those people who would be able to implement segmented patchcords aren't interested in that feature. (You'd be one of the exceptions.) So until
Re: [PD] freeverb~ roomsize / damping not working
Perhaps it's an aliasing bug, I know freeverb has some non-strick aliases. Basically, you need to compiling it with less optimization. How about the freeverb included in Pd-extended? .hc On Dec 6, 2007, at 8:54 PM, patrick wrote: hi, i compiled freeverb~ without any problem, but the controls are not modifying the sound. a theora video of the problem can be seen here: http://www.workinprogress.ca/pd/pdmtl/freeverbbug.ogg (vlc, mplayer etc...). i am on linux / pentium 4. freeverb~ v1.2 pat ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max Pd
So now the next step is building a system that lets you have the ease of jitter with the flexibility of Pd :D .hc On Dec 6, 2007, at 5:42 PM, vade wrote: This is an interesting viewpoint - at what point does providing all of these options just get in my way and make me not think about creating my own solutions - and thus really really making it mine - while extending my knowledge Im not sure, I can tell you ive had to make plenty of my own solutions with Max/Jitter - but I think you have a very valid point. There certainly are a few assumptions on Jitters part that I do not necessarily agree with. Well said. On Dec 6, 2007, at 4:10 PM, Hans-Christoph Steiner wrote: I also think that megaobjects that accept many messages/attributes become more like application preferences rather than programming, and that usually limits the possibilities. Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] freeverb~ roomsize / damping not working
hi hans, it's the freeverb~ from pd-extended using: cd pure-data/packages/ make patch cd linux_make make install (a very recent checkout-developer-layout.sh http://pure-data.cvs.sourceforge.net/pure-data/scripts/checkout-developer-layout.sh?rev=HEAD) patrick ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] segmented patchcords (was Re: PD MAX)
On Thu, 6 Dec 2007, Chris McCormick wrote: On Thu, Dec 06, 2007 at 04:24:42PM -0500, Mathieu Bouchard wrote: On Thu, 6 Dec 2007, Olivier Heinry wrote: Moreover, the code has already been desired and written, just not been implemented in vanilla. excuse me, which version of pd really allows you to edit and save cord segmentations? Didn't I once see screenshots from you of patches that showed segmented and spline curve patch chords? They were all fake because they were runtime-generated in order to look funny, instead of being user-generated and savable in order to be useful. They could also be runtime-generated and be useful, but for those who have seen the 3 screenshots and the live demos, it was clearly on the funny side. Nevertheless, wire segmentations are still on my todo list and if no-one does it for me then i'll do it one day :) _ _ __ ___ _ _ _ ... | 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] pd 0.41.0 test07 font size
On Fri, 7 Dec 2007, Roman Haefeli wrote: On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote: i'll get my wishlist engine running before soon with stuff like: - 64bit-pd (that is, not just run pd on an amd64; but have t_float/t_sample be *large*) does that mean, that every float in pd on an 64bit machine will have 64bit precision? and each sample in a table uses 8 byte ram? does it also mean, that there will be less [tabread4~] floating point rounding issues (in other words: [tabread4~] sounds 'good' up to x minutes?) A day of mono 96000 Hz sound at 64 bits per sample would take 61.8 gigs of RAM. This takes 33 bits of precision to address. This leaves 19 bits of between-samples precision for interpolation by [tabread4]. The precision of float64 is 52 bits, thus the number of significant bits is 53, still not counting the sign. Thus float64 completely includes uint53 and int54. This raises the counter problem's threshold to 9007199254740992. And yes, it would use twice more RAM everywhere. This includes the cache, so it may cause slowdown in some situations. I would enjoy it if [table] and its friends supported int16 (mere CD quality) for example. I believe that in float64 mode, pd could benefit from a float32 option on [table] too. _ _ __ ___ _ _ _ ... | 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] [tabread~~] (again)
hi i wanted to play with [tabread~~] and checked out a fresh zexy and compiled and it went fine. when instantiating [tabread~~], i get an error though: load_object: Symbol setup_tabread40x7e_tild not found tabread4~~ ... couldn't create grep -d recurse setup_tabread40x7e_tild externals/ showed me only: externals/zexy/src/tabread4~~.c:void setup_tabread40x7e_tilde(void) Binary file externals/zexy/src/tabread4~~.o matches Binary file externals/zexy/src/tabread4~~.pd_linux matches note the 'e' at the end of void setup_tabread40x7e_tilde(void) while pd says: Symbol setup_tabread40x7e_tild not found (without 'e'). i don't get it. help appreciated. 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] pd and max (2)
On Thu, 6 Dec 2007, marius schebella wrote: find last error, even if this does not work all the time, it really helped me save a lot of time. Btw, find last error in DesireData works pretty much all of the time. In PureData, find last error relies on the good will of external (and internal) developers to use pd_error() instead of error(). In DesireData, pd_error() is obsolete and deprecated. With a little more work, DesireData's find last error will be able to actually select all objects involved in the message chain leading to the error! e.g.: [loadbang] | [tgl] | [metro 666] | [f] | [symbol] would select the last three objects, because [metro]'s bang led to 0 which led to no method for float. the start of the message chain is usually [metro], [delay], [gemhead] and other clock-driven classes (so [tgl] can't be found to be the ancestor of the error). _ _ __ ___ _ _ _ ... | 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] [tabread~~] (again)
Roman Haefeli wrote: hi i wanted to play with [tabread~~] and checked out a fresh zexy and compiled and it went fine. when instantiating [tabread~~], i get an error though: this is a bug in Pd's hexloader that has been fixed in the latest and greatest 0.41-test release. altenatively you could use the hexloader to load tabread4~~. otoh, the recommended way (by upstream developers) of using zexy is still as a library instead of single externals so: are there any problems when you try to compile zexy as a lib? fmadrs. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd and max (2)
Chris McCormick wrote: On Thu, Dec 06, 2007 at 07:45:41PM -0500, marius schebella wrote: In fact, Pd has such a free license that you can even fork it and make your own closed-source commercial product out of it if you want. The only requirement is that you include the license and copyright. and having a free license does not mean that it has no licencing. a license is not the same as a license key or a license fee. instead it is a contract between the user and the owner of the code (or something like this) fgmadsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] metastudio 0.2 released
Hi all, Metastudio v0.2 is released. Some bugfixes (e.g. the sequencers now copies the current pattern properly when new is banged) and some improvements - the demoresynthfx patch contains an explaination of some machines, and a new effect - tabmask~ - an FFT phaser. get it here: http://sharktracks.co.uk/puredata/metastudio-v0.2.zip read about it here: http://sharktracks.co.uk/puredata enjoy ;-D Ed Lone Shark Aviation out now on http://www.pyramidtransmissions.com http://www.myspace.com/sharktracks __ Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [tabread~~] (again)
On Fri, 2007-12-07 at 08:00 +0100, IOhannes m zmoelnig wrote: Roman Haefeli wrote: hi i wanted to play with [tabread~~] and checked out a fresh zexy and compiled and it went fine. when instantiating [tabread~~], i get an error though: this is a bug in Pd's hexloader that has been fixed in the latest and greatest 0.41-test release. altenatively you could use the hexloader to load tabread4~~. works. thank you a lot. otoh, the recommended way (by upstream developers) of using zexy is still as a library instead of single externals yeah, works as well. i trapped myself, because i just switched a few days ago from zexy.pd_linux to singleobjectclass.pd_linux. i haven't thought about issues with filenames and i am surprised that bla~~ is a problem and bla~ isn't. however, it causes me a bit head scraping to hear that the library is the recommended format. is there a particular reason for this (i mean, since hexloader is working)? the reason, why i switched was to be aware of and avoid possible problems of my patches with pd-extended beforehand. since it is probably the quasi standard now, i would like my patches to work fine there as well. however, when loading hexloader, these problems won't show up anymore, which is kind of against the initial reason for going the single-object way. hans: [~],[~] and [tabread4~~] will load in pd-extended-0.40, right? so: are there any problems when you try to compile zexy as a lib? no. back to [tabread~~]: is there any point in using it without a [line~~] or [vline~~]? if yes, how is it supposed to be used? thanks 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
