Re: [PD] pd clicking with jack/linux
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Tue, 2008-07-01 at 00:32 +0200, Derek Holzer wrote: I run PD as root (not sudo, but real root) for click-free operation. But Ubuntu has this weird thing where you can't be root, you can only sudo. Very strange... anyways, worth a try. of course, you can become 'real' root on ubuntu as well: sudo su Or sudo -i or sudo -s Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] extremely stupid question: playing sample
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote: hard off wrote: phasor~ doesn't allow speed change at samplerate either. it allows speed change at block rate. Err, yes it does support samplerate control of speed - the left inlet is a signal inlet, and I checked the source code to confirm it: What phasor~ doesn't support is setting the phase at samplerate, as the *right* inlet is just a message inlet without support for clock-delayed messages. So you cannot start playing a sample or loop as exactly as with vline~ while vline~ cannot change the loop speed at samplerate easily. Duh. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] viewing options
Jaime Oliver wrote: Hello everyone, Is there a way to: - hide the menubar (and border lines) of the gemwin? (the menubar message doesn't do it, seems to work only on OSX) the menubar thing is to hide the osx-specific menubar; that's why it is not working. to hide the border (including window decoration) use the border message. - Use fullscreen on the secondary screen of a mulstiscreen display? [offset 1024 0, dimen 1024 768, border 0( the [fullscreen 2( message on OSX is supposed to do exactly this (with dynamically assigned dimensions of course), but the above should work everywhere. fgmsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] weird rendering order problem
Jaime Oliver wrote: Hello all, I have a very strange problem in rendering order. I have several textured polygons in render orders from 11-35 and a big textured polygon on top with a higher number gemhead, but for some reason it doesn't show on top. I have tried it in a big fat patch (where it fails) and in a simple patch where it succeeds. I also tried in the big fat patch, having everything with positive numbers and the one i want on top with negative rendering numbers, but still doesn't work. What could be causing this?: luckily rendering later does not guarantee that things are drawn on top of others. imagine a cube and behind (that is: hidden by) the cube there is a teapot. if drawing the teapot later would always draw it on top of the cube, it would be significantly more complicated (than it is now) to make more complex 3D-scenes. just think models that mutually occlude parts of each other the way this is solved in openGL is to use depth maps. whenever a fragment is drawn, it's depth value (position at the Z-axis) is stored in a separate buffer. when a new fragment is to be drawn it is first checked, whether there is already a fragment drawn at the same x/y position that is closer to the camera (and thus should occlude the newly generated fragment). if so, the new fragment is discarded. since your top polygon is obviously *not* in front of the other polygons, it will be occluded by them so you don't see it. (if they are actually at the same depth, you might get weird artefacts). this is probably crucial information if you want to mess with render-order. anyhow, there are 2 solutions for your problem: 1. just make sure that the top polygon is in front of all the rest (e.g. using [translateXYZ]) this might work ok for flat shapes without penetration. 2. disable the depth-test before drawing your polygon. this can be done with the [depth] object (which _disables_ depth-test by default) which solution is preferrably depends on the situation. if you want to make sure something is rendered to the screen (like an on-screen-display), the 2nd solution is the one to go. fgkasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] extremely stupid question: playing sample
oops, my mistake. here's the patch which i based my faulty logic on, and in hindsight all it proves is that signals are delayed one block before affecting the phasor's pitch. phasor-rate.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd-0.40.3-extended-rc2 released
Luke Iannini wrote: So, sorry to pick on the hexloader some more : ) but it seems it is the culprit. Can anyone confirm? it makes sense. could you send me the complete output of the pd-console when loading your patch with -verbose. (might get big; so zip it and send it to me privately; or put it somewhere online...) i am not sure how to handle the problem generally yet. ideas are: - remove the recursive library search in hexloader (no more hexloading for non-C externals; who is using that anyhow? libdir doesn't seem to like hexloader so much anyhow) - remove the the HEXLOADER_PATCHES functionality (it seems to be not working anyhow) - remove the entire hexloader quirks and just claim that you cannot write objects with filenames containing special characters. after all the endless struggles with hexloader, i start tending towards the last one... fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] [range] from maxlib
On Jul 4, 2008, at 12:46 AM, Luke Iannini wrote: On Thu, Jul 3, 2008 at 2:51 PM, Roman Haefeli [EMAIL PROTECTED] wrote: On Thu, 2008-07-03 at 16:05 -0400, Mathieu Bouchard wrote: On Thu, 3 Jul 2008, Roman Haefeli wrote: sorry for late reply. i couldn't figure out, what [range] from gridflow does, so it makes you difficult to have an opinion about this. the fact, that it doesn't have a '#' in its name, makes me assume, that it does something, that cannot only be applied to grids, which means, it has kind of a general use. It's a cascaded [moses]. For example, [range 11 13 17 19] = [moses 11]/[moses 13]/[moses 17]/[moses 19] where the slash is a right-outlet-to-left-inlet connection. this is what jMax had instead of moses, and I added it to GF in order to avoid having to cascade many [moses]. this speaks for keeping the name. on the other hand, i find it problematic, if libraries with a dedicated focus (processing grids in the case of gridflow) include classes, that aren't really part of that focus AND at the same time occupy a generic name. If they wouldn't be there, they would be in some library that would be required for using GridFlow (because it would be used in GridFlow's abstractions), and the problem would be exactly the same, only with one more library dependency to think about. Frankly, I don't know what to do to solve your problem. I think that it's a problem of your perception of what GridFlow is supposed to be, vs what it is. the solution would be to give it a name, that clearly relates to gridflow. [gf.range] or whatsoever (similar to grid processing classnames starting with a '#'). Besides, if you read one sentence of GridFlow is... it doesn't tell you the whole picture and you shouldn't take it as such. I also didn't want to call the library MatjuLib just because its most defining characteristic is that all the things in there are things that I have wanted and/or that my collaborators have wanted. I thought about making a separate library but quickly figured out that there was not much of a point to it. sorry, matju, i didn't meant to tell YOU what the focus of gridflow is or is supposed to be. however, it's not me, who made the distinction between 'core classes' of gridflow (the ones starting with '#' ) and some additional classes, but it's the name, that distinguishes them. this distinction made me believe, that there is something like a core part and a peripheral part (whereas the peripheral part is not necessarily necessary for the core part, that has the dedicated focus, to work properly). this might be wrong and my own faulty personal interpretation. personally i think, that something like [range] shouldn't be part of an external at all, rather should it be simply an abstraction. however, the naming problem persists (and should be faced by adding some library specific prefix, imo). Well, as always, the namespace thing is at the root of all this - if the namespace stuff was working (and it sounds like it's getting closer) then it would be perfectly fine to call it just [range] since it would require gridflow/range or import/declare gridflow to use. And, the second answer is other-language (e.g. Python) style reorganization of libraries to be author-agnostic - ordered by functionality. But, this requires a Organization Czar, it seems, and maybe no one is ready to be that person yet, so, until then, such helper-objects must stay in the homes of their authors for there's nowhere else to put them. (also, I think in this case, since grid-operators in GF have the #-prefix, those objects without the prefix are clearly distinguished as generic helpers) Actually, I think it more needs people to wrote those libraries. Cyrille and I were just talking about this here in Barcelona. Pd definitely needs working namespaces and logically organized libraries. If you also think this is important, then pick a topic and make a clean, well-organized library around it. .hc Luke ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why bother...
That looks like a very useful tool! People have tried various stabs at his (gripd, xgui, etc) but I think your approach makes a lot of sense. Using SVG means you can choose your tool to create the interface, since it is an open standard. .hc On Jul 3, 2008, at 5:52 PM, Andre Schmidt wrote: hello pd world, i have now come to the conclusion that FLOSS coding is just wasting my time, as i don't want to get abused by some dirty closed-source shameless bastards. so i won't be evolving this cool idea anymore: SimSUI - a Simple SVG User Interface - http://osku.de/simsui but as my first intention was to let it communicate with pd (add OSC to vanilla pd already!;), i would like to dedicate that small idea/ code to pd(-list), my first open-source love... i could say do what ever you want with that (lousy) code, but as long as closed-source is not illegal, every one can do what ever they want with every code, so no use to say the obvious... ask me again when the revolution starts! .andre p.s. some ass holes has/will probably software patented the idea anyway, so why bother... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
Hmm, sounds interesting. This would be useful for a better .app maker, where it only includes the files that are needed. (That would only apply on Mac OS X .app maker. The .deb maker I am working on will depend on the Pd-extended package) .hc On Jul 1, 2008, at 11:03 PM, Hans Roels wrote: hello, I've made a patch that might be useful for others. In the attached patch you can open a pd-file and the main window prints all the abstractions or externals that you need to make the patch work. It doesn't detect abstractions within abstractions though and it also prints objects like [5] or [$1], I didn't find a solution for this (small) problem yet. (I'd think it is bad pratice to use [5] in sted of [5( or am I wrong?) I wanted to make a patch that copied all the necessary abstractions and the file itself to a new folder but I ended up with this simpler solution... hans rprint-non-vanilla- objects2.pd___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] print all abstractions and externals
excellent! that is so useful. thanks for sharing. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] make money not art
Hi, has someone experience in distributing and probably selling pd standalones? I was thinking of a combination of flash interface (or Gem?) and sound patch. right now I think the best way to do this would be to create an executable application for every platform and architecture including the used external libraries. The patch would start up in -nogui mode, although I am not sure how to handle sound settings from within the application. In case I wanted to use Gem, besides from including the license, would I also have to include the Gem sourcecode in the package? marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] cheap AVR/HID sensor board
More news about this project? I just found this thread now, it's a very smart path... can you suggest more links about that? thanx for sharing cheers glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd-0.40.3-extended-rc2 released
I removed the hexloader from my startup, and the time to load for my main patch dropped down from 5 1/2 min to 1 min. Wonderful. On Fri, Jul 4, 2008 at 1:37 AM, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: Luke Iannini wrote: So, sorry to pick on the hexloader some more : ) but it seems it is the culprit. Can anyone confirm? it makes sense. could you send me the complete output of the pd-console when loading your patch with -verbose. (might get big; so zip it and send it to me privately; or put it somewhere online...) i am not sure how to handle the problem generally yet. ideas are: - remove the recursive library search in hexloader (no more hexloading for non-C externals; who is using that anyhow? libdir doesn't seem to like hexloader so much anyhow) - remove the the HEXLOADER_PATCHES functionality (it seems to be not working anyhow) - remove the entire hexloader quirks and just claim that you cannot write objects with filenames containing special characters. after all the endless struggles with hexloader, i start tending towards the last one... fgmasdr 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
