Re: [PD] isn't the GUI supposed to have lower priority than process?
Hi Matteo, On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote: > I always thought that in PD, "process" (i.e. dsp and control processing) had > the priority over GUI rendering, in such a way that drawing the gui would > NEVER cause audio clicks although this means there's no warranty about how > much gui rendering may be delayed. > > To my great disappointment, I see that when opening a subpatch with a lot of > gui, audio clicks are produced. Just opening it, i.e., right-clicking on it > and "open" (or just left-clicking when not in edit mode) > Not to mention moving around a "big" GOP-enabled object (or, I guess, a > handful of gui elements at the same time). > But the first one seems to me a much more severe problem. > > Do you know of any workarounds? > Do you know if this is Windows-specific? > I haven't experienced this problem myself because I hardly use any GUI stuff in performance. However, one way to avoid it might be to run two instances of PD, one for the GUI, and one in -nogui mode, and use some network protocol (OSC, FUDI), to send data between them. That way you have your GUI and audio processing running as seperate processes in the OS. At least on *n*x you can then optionally assign a priority to each process using something like 'nice'. Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Clickable gop data structures
Hi, I'm just starting to get my hands dirty with data structures. In particular GOP data structures. Inspired by Chris Mccormick's wonderful s- abstractions, I'm trying to make a simple GOP transport, with graphical play/stop/pause rewind etc. controls. The main showstopper at the moment is that I don't seem to be able to make the UI elements 'clickable'. Using [tot] I can detect the mouse position when clicking inside the subpatch, but when the graph is on parent, this doesn't work. Of course, I don't want to use [tot] in the parent, because the GOP subpatch might well move. Is there some other way to make a clickable element? Chris's s-env abstraction seems to detect ctrl-click, but It isn't obvious to me how this is achieved... Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Clickable gop data structure
On Wed, 2007-06-06 at 23:05 -0400, Chris McCormick wrote: > On Tue, Jun 05, 2007 at 11:45:37AM +0200, Frank Barknecht wrote: > > > > Some other click-detections things require more manual work: The > > [struct] object has an outlet that will send out messages if a pointer > > of that type was selected or changed. Just connect a [print] there to > > see what's happening. You can use this with [route ...] to trigger > > actions when data structures are changed. > > I seem to remember a release where this detects just plain old mouse > clicks (i.e. no drag or modification) so that you could build your own > 'toggle' for example. Am I just dreaming that or is it real? I can't > find anything in the docs about the struct output, though I know I've > used it before. > Yes, this is what I was really after. I tried Frank's suggestion, and [struct] does 'detect' clicks, but only in edit mode and not for GOP. In the end I used Geunther's [image], which does the job, but isn't ideal i) because of the external dependency and ii) because there's no image scaling, but does enable you to make nice looking buttons if you hide a bang behind it. Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] elitism, software and academia (was GEM FTGL Sadness)
Hi Jared, On Thu, 2007-06-07 at 07:16 +0100, jared wrote: > While I'm ranting :-)In my academic experience, it's often frowned > upon to use other's patches in your own compositions because it seems > that the patches themselves are the work of art; and it's almost as if > this is considered plagiarism. I don't know what your academic experience is, but there is a lot of evidence to suggest the opposite of what you are saying. The sharing of PD patches and abstractions is commonplace in the PD community. Currently in the CVS there are: pd/ 424 pd patches externals/ 3464 pd patches abstractions/ 953 pd patches That doesn't include ad-hoc patches people have shared via the mailing list, of which I have 847 on my computer grabbed from the list archive. All of these are publically available, and free for use in your own work. They range from simple help files to complex abstractions and patches. > I think academia needs to recognize that there are many composers who > use computers as a means to an end; I find this patronising, almost offensive. Do you have any examples of academics who don't recognise this? Even if you do, you shouldn't make generalisations about an entire community based on a few personal examples. > who make music with the AID of > computers; not to make music WITH computers. Could you explain the difference? > There is still a rigid > line that separates the composer and the programmer. Where is this rigid line? Do you have any evidence for it? As far as I can tell there exists a continuum like this: composer <-> composer/programmer <-> programmer I know many people who are in the middle of this - straddling the 'line' between composer and programmer. > Most Music > curriculums are still classically based. Most Music Technology > curriculums are programming based. I'm not sure if this is true or not, but if it were, it might be because there is 'most' demand for classically-based music courses and 'programming-based' music technology courses... However, in the UK, there are many jazz-based and other non-classical graduate music courses, as well as music technology courses that contain no programming elements at all. There are also hybrid 'Sonic Art' courses that bring in elements from the visual arts, music and information technology. I suspect this the case in other countries also. > What about today's composers who are > interested in classical compositional techniques and forms, but who are, > at heart, electronic music composers and want to apply these classical > techniques and forms to their electronic compositions with the AID of > technology, yet have no interest in programming? They should use software that doesn't require any programming. I would suggest something like Beast (http://beast.gtk.org) if they are Linux, Bidule (http://www.plogue.com/) if they are on Mac OS, Audiomulch (http://www.audiomulch.com/) if they are on Windows. Any of these would provide a good entry point for beginners who could later move on to something with a dataflow programming element like PD. Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] elitism, software and academia (was GEM FTGL Sadness)
Hi Jared, On Fri, 2007-06-08 at 18:39 +0100, jared wrote: > > >I don't know what your academic experience is, but there is a lot of > > >evidence to suggest the opposite of what you are saying. > > Then I attended an institution whose policies are different than the > others. > That's really my point: you can't really generalise about academia because it comprises of an international group of (often unrelated) people and organisations. Some of these share common traits, others don't. > > > I think academia needs to recognize that there are many composers > who > > > use computers as a means to an end; > > >I find this patronising, almost offensive. > > Why so overly sensitive? This wasn't an attack on anyone. It is an > opinion, not an accusation. Did you not see the smiley faces? > Smile :-) > Sorry about that, but it was the generalisation that I didn't like. I would have thought it was a perfectly fair comment if you had put 'I think certain academic institutions need to recognise...' > > I won't name anyone. One example: I had 'programming' classes where I > had to create compositions with Max/MSP and Csound. Instead of using > shared patches/orch files we had to build and use extremely basic > instruments; rarely anything more than an oscillator, filter and an > LFO. So, instead of being encouraged to use shared instruments which > would result in having a composition with some 'character', I have a > couple semesters’ worth of compositions full of bloops, beeps and > sirens. No offense to bloops, beeps and siren lovers :-) I just don't > find it aesthetically interesting. I would have loved if we had fewer > assignments so we could have the time to build our own more > interesting sound generators to include in our compositions. Or, we > should have been allowed to pick and choose between the plethoras of > shared instruments. It sounds like that course wasn't for you :-/ > > >Even if you do, you shouldn't make > > >generalisations about an entire community based on a few personal > > >examples. > > So if someone finds, what they believe to be, something missing from a > system, they shouldn't speak about it? That's rather dangerous > censorship, I believe. That's not what I'm saying at all. The thing is that you haven't found something missing from a system, you've found something missing from a specific institution within a system. I am therefore suggesting that you restrict your comments to that specific case (albeit anonymously) unless you can be sure that they really do apply to the entire system. > > >Where is this rigid line? Do you have any evidence for it? As far as > I > > >can tell there exists a continuum like this: > > > > composer <-> composer/programmer <-> programmer > > > > Do you see that slash that you've put between composer and programmer? > That's the rigid line. Do you notice how the composer and programmer > on opposite sides of the spectrum? That's the rigid line. The slash is intended to indicate someone who is a composer and a programmer. Perhaps I should have indicated the continuum on some sort of 4-dimensional hyperplane ;-) > Therein lays the rigidity. Who forms this 'demand'? Is this the > demand because these are the only two options available? I believe > that today's generation of music students would be more interested in > grey, not black and white. I would imagine that some of them are interested in grey, some of them are interested in black and some of them are interested in white, and some of them are interested in black, white and grey... > > > >.as well as music technology courses that contain > > no programming elements at all> > > > > Please let me know of such courses. I'm not being facetious...this is > the type of program that I am interested in. Are you looking for a course largely oriented towards enabling you to author your own artistic outputs (e.g. pieces of music/sound art), or a sound recording/production course, or a bit of both? I only really know about UK Universities, but I will try to help if I can. > > >Bidule (http://www.plogue.com/) if they are on Mac OS, Audiomulch > > >(http://www.audiomulch.com/) if they are on Windows. > > I'm glad you mentioned those programs...I wonder why aren't they more > utilized throughout academia? I would have loved to be able to use > Bidule and Audiomulch for my compositions. > Yes, the irony of this debate is that I actually agree with your point that there is a need for (preferably FLOSS) tools that provide an easier, more accessible, more user-friendly, more immediate route into composition and performance with technology than some of the Music N derivatives (Pd, Max/MSP, Csound SuperCollider etc). You might be interested in a project I'm currently involved in to start addressing some these problems (www.integralive.org). best, Jamie ___ PD-list@iem.at mailing list UN
Re: [PD] Question about possible SQL/MySQL Externals
Hi Mike, I did some work on this last year, but gave up for lack of time. I basically renamed it to psql, and changed the code so that it doesn't open, close and flush the database for every query, i.e. no more 'single'. If you are interested, I can send you the source tarball + diffs off list. Jamie On Mon, 2007-06-11 at 07:28 -0500, Mike McGonagle wrote: > http://www.reverberant.com/PD/sqlsingle.tar.gz > > > Thanks a lot for this, I am currently using MySQL, but I am sure that > this will serve as a template. > > > Mike McGonagle > > On 6/8/07, Alexandre Quessy <[EMAIL PROTECTED]> wrote: > > HI all, > > You can try sqlsingle, that is an interface to PostgreSQL. > > http://lists.puredata.info/pipermail/pd-list/2001-02/001829.html > > > > Must be somewhere in the CVS. > > > > a > > > > 2007/6/3, David Powers <[EMAIL PROTECTED]>: > > > To be honest, I've never had complete success getting py/pyext to run > > > ... ie. only about half of the help patch seemed to work on winxp. > > > > > > Well, I'm going to d/l a new pd-extended right now and see if I have > > > better luck. Haven't tried a recent release in some time for fear of > > > breaking Gem. > > > > > > ~D > > > > > > On 6/3/07, Thomas Grill <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > this has already been discussed a couple of times... it should be > > > > straightforward using the Python scripting language (via py/pyext) > > > > and the modules that come with it. > > > > greetings, > > > > Thomas > > > > > > > > Am 02.06.2007 um 22:56 schrieb David Powers: > > > > > > > > > This would be awesome, could do some really cool net art projects > > > > > with this. > > > > > > > > > > ~David > > > > > > > > > > On 5/30/07, Mike McGonagle <[EMAIL PROTECTED]> wrote: > > > > >> Hello all, > > > > >> > > > > >> I was wondering if anyone had thought of creating an interface set of > > > > >> externals for storing and retrieving data from a Database? Basically, > > > > >> I was interested in seeing if anyone has created some externals that > > > > >> do basic SQL transactions. > > > > >> > > > > >> Or is this something that is not very practical? > > > > >> > > > > >> Mike McGonagle > > > > >> > > > > >> If you think you can, or you think you can't, you are probably right. > > > > >> —Mark Twain > > > > >> > > > > >> ___ > > > > >> 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 > > > > > > > > > > > > > Thomas Grill > > > > http://g.org > > > > > > > > > > > > > > > > > > ___ > > > PD-list@iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > -- > > Alexandre Quessy > > http://alexandre.quessy.net > > http://www.puredata.info/Members/aalex > > > > ___ > > PD-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] nqlbyl
Hi, Please find attached a little abstraction that some may find vaguely useful. It is a piece of logic that filters out jumps in the input stream - a bit like CNMAT's Max external [lbyl] but 'not quite' (hence the name). Suggestions for improvements welcome. BTW: I started by trying to a full [lbyl] as an abstraction and gave up, but I'm sure it would be possible if I had a clearer head... Jamie #N canvas 469 128 353 549 10; #X obj 174 139 inlet; #X obj 144 212 -; #X obj 144 239 abs; #X obj 107 140 inlet; #X obj 107 432 spigot; #X obj 107 172 t f f f; #X obj 107 456 outlet; #X obj 196 324 f; #X obj 196 349 == 0; #X obj 163 349 == 0; #X obj 163 374 &&; #X obj 144 396 ||; #X obj 144 295 t f f f b; #X text 12 38 Discards values that jump by more than; #X obj 10 13 cnv 15 300 20 empty empty empty 20 12 0 14 -261681 -66577 0; #X text 23 16 [nqlbyl]: not quite lbyl; #X obj 144 262 <= \$1; #X text 11 56 +/- the the value set by the right inlet or arg1; #X text 11 72 but if a further jump takes place we assume; #X text 9 90 it is back to the original value or intended; #X text 19 518 Jamie Bullock 2007; #X connect 0 0 16 1; #X connect 1 0 2 0; #X connect 2 0 16 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 5 1 1 1; #X connect 5 2 1 0; #X connect 7 0 8 0; #X connect 8 0 10 1; #X connect 9 0 10 0; #X connect 10 0 11 1; #X connect 11 0 4 1; #X connect 12 0 11 0; #X connect 12 1 9 0; #X connect 12 2 7 1; #X connect 12 3 7 0; #X connect 16 0 12 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] cross-correlation in pd ?
Hi, On Sun, 2007-06-17 at 23:01 -0500, Charles Henry wrote: > Jamie Bullock has cc~ in his flib collection. It computes cross > correlation in the time domain, and cross-covariance using the freq. > domain. I worked on it a while back...but have been lazy about trying > to change the cross-covariance into a cross-correlation. Sorry, > Jamie. > flib is now deprecated, and has been surpassed by libxtract, which is a generic C library that includes as an example a PD external that wraps it's functionality. It can be found at http://sourceforge.net/projects/libxtract. If you want to use the fft-based autocorrelation you will need the fftw library, and to compile libxtract with --enable-fft. It includes a time domain and fft-based autocorrelation, but no arbitrary cross correlation functions. Chuck, I must remember to add your cross-covariance code into libxtract (with acknowledgement of course). best, Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] dssi~
Hi Victor, On Thu, 2007-06-21 at 20:58 +0200, victor wrote: > I compiled dssi~ on debian etch (adjunt) but dont appear the text of > object's box, using pd extended. I supose the use is: > [dssi~ /path/to/plugin] > > > dssi~: DSSI/LADSPA host - version 0.96 > > > dssi~: error: plugin not loaded > dssi~ has one compulsary creation argument. This should be either the plugin label: [dssi~ sine_faaa] ..or the path to the library and the plugin label separated by a colon: [dssi~ /path/to/sine.so:sine_faaa] There is a file called dssi-manual.txt in the doc/ directory that comes with the dssi~ source tarball that explains this and some other pretty essential info. > After that error message I must to restart pd, because only may to see > object lines, not text. I think this is due to a bug in a certain Tcl/Tk version. If you can, you should try to upgrade to a more recent version. Let me know if this _doesn't_ fix the problem. best, Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
On Tue, 2007-07-03 at 13:00 -0400, Mathieu Bouchard wrote: > On Mon, 2 Jul 2007, Thomas O Fredericks wrote: > > > Yes, everything does have to be in a category. This constraint makes > > for an environment that is especially useful for newbies and resolves > > a lot of conflicts. > > verb/is article/this noun/sentence adjective/easier prep/to verb/read ? > Yes, but how do you resolve: verb/colour noun/colour adjective/colour or... video/colour audio/colour As humans we differentiate between these by their context, but PD is not that clever... Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] org.puredata.plist in Mac bundle
Hi, With Pd-extended it seems that it is possible to leave the .plist file inside the .app bundle, and Pd will read it from there. How is this achieved? I would like to take a vanilla Pd, and have it read the .plist file from inside the bundle rather than (~)/Library/Preferences. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [; pd init(
On Tue, 2007-09-18 at 10:51 -0700, Miller Puckette wrote: > "init" is one of many messages that Pd and its gui send back and forth, which > aren't intended to have any user-level functionality... of course, some > of those messages like "connect" have proved useful at the user level; but > none of them are guaranteed to do anything useful or even to be safe. The > only one that's "supported" is "dsp" for turning audio computation on and off. > So, from this, I guess that Pd doesn't 'officially' support dynamic patching... Are there any plans to add a user-level dynamic patching mechanism at some point? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] one laptop per child
On Tue, 2007-09-25 at 05:31 +0100, Andy Farnell wrote: > > OLP*C* - for a child there is no doubt, Pd is vastly easier > to understand and use than Csound. I had a play with one of the OLPC machines at GUADEC this year, and Csound is well buried beneath a polished GUI. I presume they chose it because of the all the built-in and instantly usable opcodes/ugens. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 2007-09-26 at 11:57 -0400, Stephen Sinclair wrote: > > > It would be nice to fix it, but unfortunately doing so would probably > affect backwards-compatibility with people's patches. > Anyways, if you have something which absolutely depends on the order > in which a message is sent out multiple connections, insert the [t] > object to re-trigger the same message several times, and make one > connection per outlet. Messages will be ordered from right to left. > > My patches are just full of triggers like this. > ...so are my _Max_ patches, otherwise I find things quickly become a complete mess (visually and logically). Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 2007-09-27 at 03:10 +0200, tim wrote: > > If you need to have a specific execution order, then you should use a > > [trigger]. It makes it explicit, which is a good thing. > > > > > Hello, > > What makes this a bit tedious is that, if you insert a new argument > inside [t b b b] to get [t f b b b], the connections already in place > don't move one place to the right, so you have to manually remove and > redraw all of them. > Does anyone know if a feature request has ever been submitted for that? If not, I will gladly submit one. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] timestretching for slicer
On Tue, 2007-10-02 at 23:18 +0900, hard off wrote: > cool!!! Can you post a simple patch that does abelton-esue > time-stretching on a loop? > Isn't the technique demonstrated in the Pd help patches B14.sampler.rockafella.pd? Or have I misunderstood the question? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] timestretching for slicer
On Wed, 2007-10-03 at 16:36 +0200, Derek Holzer wrote: > No, he's talking about changing sample length and pitch independently. > Or changing length without changing pitch at all. This is done with FFT > or granulation, ...but that's exactly what sampler-rockafella does. > not just changing the playback rate alone. It uses a windowed overlap-add. I suppose that's quasi-granular. best, Jamie > -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] about pd
On Wed, 2007-10-10 at 22:38 -0500, Charles Henry wrote: > > As loing as it is not the crap beer we make in America! ;) > > I know what you mean... I could go for a nice Stella Artois or a > Peroni... or a dozen Harboes... > That's not beer! How about a pint of 'Old Speckled Hen' or 'Bishop's Finger'... *English* beer. Oh, hang on a second, isn't this thread supposed to be back on-topic ;-) Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] about pd
On Fri, 2007-10-12 at 17:33 +0100, Andy Farnell wrote: > > Wine. Not now because I don't have the space.. but I've > always been fascinated by wine-making and the chemistry of it > all. As a kid we had a country house with lots of space and land > and always rows of demijohn bottles bubbling away. Amazing what you > can get to brew, almost any fruits or sugary plant will work, some > I remember are > > Nettle - the nasty stingy things make good wine. > Blackberry > Strawberry - really yummy > Elderberry and elderflower - subtle and dry > Cannabis - yep, you can make dope wine > Plum - very sweet wine > Sloe - "sloe gin" from really bitter fruits > Gooseberry - the green pimply ones > Rose Hip - a very English wine > Tea - never thought it had any sugar but folks make tea wine > Mead - wine made from honey is amazing > That's fantastic! I'm loving this thread! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOM experts...
On Sun, 2007-10-14 at 17:41 +0200, [EMAIL PROTECTED] wrote: > i don't know, georg should be able to help you here. > nevertheless, bear in mind that [ann_som] is a standalone > implementation and has nothing to do with FANN (well both are dealing > with ann, obviously but that's it; i didn't know of fann when i wrote > [ann_som]) > There was a 2007 SoC project that involved adding a SOM API to FANN. I think it's only in CVS at the moment, you need to check out the gsoc2007 branch. I haven't really looked at it yet, but I guess once it's released, it would be nice to add an [ann_fsom] or whatever to the PD ann collection. best, Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] many paths, how
On Wed, 2007-10-17 at 00:08 +0200, Frank Barknecht wrote:
> Hallo,
> Atte André Jensen hat gesagt: // Atte André Jensen wrote:
>
> > My paths section in my preferences is full, and I need to ad another.
> > remember there was some discussion recently about how to add more, but I
> > can't seem to find it. Could anyone refresh my memory?
>
> Hm, this gets asked (and answered) once every 1.5 weeks. What can we
> do about it?
It is also one of the most frequent questions I get asked when I
introduce new users to PD. Personally I think the entire 'search paths'
window is badly designed. I have a few ideas about how it might be
improved:
1/ 'Save all settings' and 'Apply' should be removed.
2/ The path list should have a dynamically generated scrollbar, so that
when the list exceeds a certain length (10), the scrollbar appears and
the user can view the additional paths by scrolling up/down.
3/ It should not be possible to type directly into the path list, only
select a list element or group of elements (paths).
4/ Two new buttons should be added directly underneath the path list:
'Add' and 'Remove'.
5/ 'Add' opens a new dialog ('Select path...') whereby the user can
either enter a path or navigate to it using a filesystem browser widget.
Once the path has been entered (or selected), clicking 'OK' adds the
path to the path list and closes the 'Select path...' dialogue.
6/ Clicking 'Remove' in the main 'path list' window will remove the
currently selected item(s) from the path list.
7/ Clicking 'OK' will commit changes to disk, apply them for the current
session and close the window.
8/ Clicking 'Cancel' will discard the changes and close the window.
Just a few thoughts. If anyone else thinks this is a good idea, I would
happily put a feature request on the tracker.
best,
Jamie
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] sound annotation
On Wed, 2007-10-17 at 17:22 +0200, [EMAIL PROTECTED] wrote: > hello list, > > I am looking for a way to annotate sound, so to associate text information > to sound files. Would it be a way in pd to do it? > > I would need to create time stamps in a sound file and associate keywords > and notes to these nodes. I have searched the archives looking for this > but perhaps has been called differently. I hope somebody can give me some > clues where to find out more about this. > You might find the aubio library useful: http://aubio.piem.org/ Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [-SPAM-] Re: many paths, how
On Thu, 2007-10-18 at 10:29 +0200, IOhannes m zmoelnig wrote: > Jamie Bullock wrote: > > > > It is also one of the most frequent questions I get asked when I > > introduce new users to PD. > > interestingly enough i never have been asked this. > most likely it is not the initial design that a lot of paths are to be > added. Thinking about it, the people who ask this have generally come from Max/MSP, so not necessarily complete newbies. > what i am dearly missing in your design is: > > 9) buttons to re-order the paths > (since you cannot add change the paths directly, and i think it is very > re-order paths in a way that involves opening several windows) > in my work-cycle, path-order is a crucial thing when it comes to getting > the "right" object. I agree - there should be some easy way to do this. IMO, the nicest thing would be for each path to have an anchor, which when clicked, rather than selecting the path, enables the path to be dragged up and down the list. I'm not sure how feasible this is in Tk though. Perhaps a pair of 'up-down' buttons adjacent to each path would be easier to implement: ^ v Clicking the top button moves the path up the list. Clicking the bottom one moves it down. > 10) unify the path and startup dialogs into one single (possibly > multi-tab) dialog. I completely agree. I forgot about the startup dialog! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [-SPAM-] Re: many paths, how
On Thu, 2007-10-18 at 16:47 +0200, Frank Barknecht wrote: > Hallo, > Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > > > I think it would be very good to have cleaned up preferences windows > > for Pd in general. > > I hate to say this: But a lot of these problems are already solved in > Pd and Pd-extended. The solution is called ".pdrc", and I'm personally > still using it. Yeah, I love .pdrc too! The thing is that if we are in a situation where it is easier to edit the prefs 'manually' in a text editor, there is something seriously wrong with the UI and it should either be changed or removed, otherwise things can get very frustrating (particularly for new users). Anyhow, I just followed Patrice's suggestion, and it looks like a lot of the things that are being suggested for a potential prefs redesign are already implemented in desiredata... Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended final release candidate - please test!
On Sat, 2007-10-13 at 17:03 -0400, Hans-Christoph Steiner wrote: > Please test this build lots! If no one finds anything that needs > fixing, I am going to release this exact version: > > http://autobuild.puredata.info/auto-build/2007-10-13/ > > There are some known bugs, but they are big and will have to wait for > the next release. Other than that, let's make sure there are no > other outstanding issues. > One minor point: I don't know if this goes for other helpfiles, but clicking the all_about_hid bang/button in the hid help results in a 'No such file or directory' error. The abstraction is looking in extra/pddp, when the file all_about_hid.pd is actually in doc/5.reference. Ubuntu feisty install from .deb Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Tue, 2007-10-23 at 01:00 +0200, Jeff Rose wrote: > > My real question is how to work with arrays in this manner. I'd like > to use [line] objects to generate small sequences that I write into > short segments of an array. With a for loop this would be straight > forward, but I don't know how to iterate through an array, or how to > generate the line instantaneously rather than having it take some > amount of time like you normally would use line for an envelope or > something. [until] is Pd's looping mechanism. > Anything like a priority queue in PD, so I can just > have my delay's pop off the queue? I think PDcontainer does this (http://grh.mur.at/software/pdcontainer.html) > Also, how tough is it to > dynamically create objects from within patches? If you have pd-extended there is some info under the documentation browswer under manuals/pd-msg/. BUT, I don't think dynamic patching in Pd as it currently stands is officially supported (by Miller), and unexpected things can happen! That said, I generally haven't had too much trouble with it, YMMV. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd-0.39.3-extended released!
On Sun, 2007-10-21 at 13:41 -0400, Hans-Christoph Steiner wrote: > Finally, it's done! The most polished release of Pd yet. We are > further refining Pd into a truly powerful and usable programming > platform. > Congratulations HC! This is a fantastic achievement. I now have Pd working consistently across the three platforms I use for development. I think portability, consistency and ease of installation are very strong advantages for pd-(extended) over other environments for 'computer music' (Csound, SuperCollider etc) all of which are significantly harder to get up and running with anything like a complete set of functionality. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Tue, 2007-10-23 at 15:03 -0400, Mathieu Bouchard wrote: > On Tue, 23 Oct 2007, Jamie Bullock wrote: > > > BUT, I don't think dynamic patching in Pd as it currently stands is > > officially supported (by Miller), > > It's quite useless to say that, unless you are interested in the > philosophical aspects of whether dynamic patching is a feature of pd, what > is a feature, and the meaning of "official" and perhaps of "is". At least > several commands of dynamic patching are so much used that Miller can't > remove them, and if he did, then Hans would put them back anyway. > > > and unexpected things can happen! > > What are you talking about? > http://lists.puredata.info/pipermail/pd-list/2007-09/053892.html ...unless you are interested in the philosophical aspects of whether crashing is a feature of pd, and the meaning of "unexpected" in the context of the following: > > "init" is one of many messages that Pd and its gui send back and forth, which > > aren't intended to have any user-level functionality... of course, some > > of those messages like "connect" have proved useful at the user level; but > > none of them are guaranteed to do anything useful or even to be safe. The > > only one that's "supported" is "dsp" for turning audio computation on and > > off. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
Hi Jeff, On Tue, 2007-10-23 at 14:37 +0200, Jeff Rose wrote: Anyways, it would be great to hear > what experienced people have to say about dynamicity in PD. > You might want to take a look at Thomas Grill's [dyn] http://www.parasitaere-kapazitaeten.net/ext/dyn/ Although, I think if you fancy this route, you should probably check out the latest CVS version. With regard to dynamicity in PD in general, I think if you want to do something like a polyphonic synth, then it would be better to statically allocate the voices than try to do it dynamically in PD. Either that, or use something like Csound (via [csoundapi~]) to do the synthesis. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Array indexing for the wind and the birds
On Tue, 2007-10-23 at 13:40 -0400, marius schebella wrote: > Frank Barknecht wrote: > > Well, yes, it was a pretty fundamental decision. Languages like > > SuperCollider, Nova and Csound to some extent show, that dynamically > > creating synthesis objects can work in a realtime system as well. > > and not to forget > http://chuck.cs.princeton.edu/ > marius. > ...and indeed [chuck~] ! http://www-static.cc.gatech.edu/ugrads/m/mjr/chuck~/ Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fun with Lua coroutines
On Wed, 2007-10-31 at 21:11 +0100, Frank Barknecht wrote: > If not, lua may be the easiest start: It's easy to compile, compiled > versions could be statically compiled, the language is fully documented > with a wonderful book (see www.lua.org). > [snip] > > Language freaks (nerds) can find some nice features as well. The > coroutines feature that started this thread is an example, closures > and recursion are others. > Damn you Frank, you just made me want to go and learn YAL (Yet Another Language)...! That's another couple of weeks (or maybe years) of my life down the drain ;-) Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] new pd wiki - practical data - includes forum
On Sat, 2007-11-03 at 14:53 +0100, Steffen Juul wrote: > On 03/11/2007, at 8.02, hard off wrote: > > > i just set up a new wiki for pd, aimed at providing a simple and easy > > way for pd users to share their patches / tutorials, etc... > > There is also the http://puredata.info website people can use. For > tutorials for instance folks can add to http://puredata.info/docs/ > tutorials > Also, as (I think) IOhannes states on the puredata.info site, it is also possible to set up a forum inside the Plone site (puredata.info) e.g with zforum (http://plone.org/products/zforum). Maybe this would be a better place for it, to keep things centralised a bit... Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [-SPAM-] changing the look of Pd to be more readable
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote: > I think there is a lot that could be done to the look and feel of Pd > that would make it much more efficient and usable. I think it is > crucial to avoid flashiness, one of Pd's strengths is its lack of > flashiness (no segmented patch cords! ;) But small things can make a > big difference. > I really like some of these ideas, and I do agree that a few subtle visual nuances would bring Pd's UI into the 21st century! I always thought that om/ingen (http://wiki.drobilla.net/Ingen) had a a really nice UI - just the right combination of minimalist simplicity and graphical niceness (anti-aliased splines!). Maybe we can steal some ideas from that. Can I put a vote in for _not_ putting arrows on the end of patch chords. This is one of the features of Desire Data that I really don't like since it adds no additional information to the patch (it isn't possible to connect from inlets to outlets), and it adds visual noise. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI speed test
On Mon, 2007-11-12 at 15:01 -0500, Hans-Christoph Steiner wrote: > I devised a quick test of loading speed and did some quick > comparisons on my MacBook Pro 2.4GHz. (I am used to having one of > the slowest machines around, my old 800Mhz Powerbook, so I still > have > to readjust my thinking). Here's my times: > > 14ms Pd-0.39.3-extended > 6.5ms Pd-0.40-2 vanilla > 16ms Pd-0.40.3-extended-2007 > I get rather sporadic results with 0.39.3-extended: 5.019 8.171 7.637 10.828 4.997 Pd-0.40-2 vanilla is more consistent: 9.499 9.337 9.525 9.42 9.585 Ubuntu Gutsy on Dual-core 2.6GHz Macbook pro uname -r: 2.6.20-16-lowlatency Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] what about NRPN's ?
On Fri, 2007-11-30 at 10:22 +0100, David Schaffer wrote: > Hi! Does anyone know if Pd can handle RPN-NRPN messages? thank you! > It can with David Mccallum's excellent abstractions: [nrpnin] and [nrpnout]. http://www.mentalfloss.ca/sintheta/html/downloads.html Jamie -- www.postlude.co.uk ___ 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)
> > There are occasional times when segmented patchcords make a patch > more readable, but the vast majority of the time, they are a > distraction at best. I have watched so many Max users spend quite a > bit of time segmenting and organizing their patchcords. If they > instead put that same effort into organizing the code, using > subpatches, etc., the code would be much more readable and maintainable. > I agree, with the addition that using segmented patch chords also encourages people to optimise for readability too early on in the patch programming process. A lot of time can be wasted if people focus too much on making things look good early on in patch creation, only to find it needs to be reorganised at some later point. Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] phasor time scaling
Hi, Has anyone implemented 'phasor time scaling' as an abstraction (or external)? I know it is relatively easy scale a phasor where the frequency of the scaled phasor is an integer multiple of the master phasor: [phasor~] | [*~ 2] | [wrap~] ...but what about non-integer multiples, and fractional scaling? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Get patch file name
On Fri, 2007-12-07 at 22:14 -0800, Luke Iannini (pd) wrote: > Hi all, > I have searched high and low for a way to get a patch's file-name, and > am quite surprised that there seems to be no way to do it. > > > I was about to set out making a Subversion library so I could get the > status of my patches (and commit changes) from inside Pd. But that's > quite impossible without this object. > > > [getdir] can get the patch's directory; that's as far as I got. In CVS: postlude/getpatchname should do the trick. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Hi Andy, On Fri, 2007-12-07 at 16:12 -0500, [EMAIL PROTECTED] wrote: > i installed postgresql, and got it running, created a user for myself, > compiled [psql] from postlude (i'm using pd-extended from cvs). > > i opened up the psql-help file and started with the first instruction, and > it created the database fine, i moved to the second command and get this > error: > psql: Action failed. PQresultStatus is PGRES_FATAL_ERROR > > i'm wondering where i can look for more information about what is going > wrong, and what i can do to fix it. I think you are experiencing this because the DATETIME type is deprecated, and the helpfile is hopelessly out-of-date. You can confirm this by 'tailing' the logfile whilst running the query: sudo tail -f /var/log/postgresql/postgresql-8.2-main.log That's assuming you're on Unix/Linux, although I'm sure there must be some way to watch the log on Windows also. You should see the relevant error there. You might also want to test the external by trying the 'CREATE TABLE' query without including the datetime column. > i think it would be wonderful if i could start using a database to store > values :) > Indeed. You might also want to look at the new SQLite external Mike is working on. HTH, Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Hi Hans, I like this idea of a hot and cold inlet, and I can see where you are going with making the database access objects more pd-like. I also agree that the sql/sqlend delimiters are a rather inelegant workaround for Pd's lack of a string type. What you suggest shouldn't be too hard to implement either. I have a few specific comments (see below). On Fri, 2007-12-07 at 21:37 -0500, Hans-Christoph Steiner wrote: > That is done by sending the [submit( message to the hot inlet. Or do > you mean having multiple SQL calls separated by semi-colons? If you > wanted to add semicolons, there would have to be a special message, I > think we could just reuse the "addsemi", "addcomma", "adddollar" > messages from message boxes. This feels like another workaround, but I suppose it's more idiomatic pd than 'sqlend'. > > As far as I know, the semi-colon at the end of the statement in SQL > triggers the execution of that statement, so I can't see an advantage > to having multiple, semi-colon terminated statements in a single > message box. Does it change how the SQL is executed if they are > submitted at the same time? No. > > > > The other thing I think that would have to be is forcing all input > > SQL to go into the second inlet. Allowing some things to go into the > > hot inlet, while others are required to go into the second outlet > > would make it difficult to use because you would have to remember > > which type of statement can go where... > > > Any SQL statement would be allowed on the cold inlet. Because of the > limitations of Pd (no escape mechanism), and the fact that commas > already have a meaning in Pd messages, the hot inlet would not be able > to handle commas (unless someone comes up with something quite > clever). I think we should either come up with something quite clever (using regex springs to mind), or not allow queries to be submitted to the hot inlet at all. Having a hot inlet that doesn't quite handle queries in the same way as the cold inlet is just confusing. Another suggestion: perhaps it would be even more idiomatic to use "bang" instead of "submit" as the 'quert send' message? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Sat, 2007-12-08 at 00:51 -0500, Mathieu Bouchard wrote: > The only SQL interface I'd really be happy to use (if I had to use SQL) is > something using placeholders, sort of like [expr], but perhaps written in > the usual SQL style: > > [sql select * from candies where flavour=? and colour=?] > Interestingly enough, that's pretty much how Mike started off with his SQLite object. Then I persuaded him that passing the queries as a list to the inlet would be more flexible. It also greatly reduces the number of objects required to send a query, if you have more than one query. I also agree with Hans about being consistent with other Pd objects esp. [textfile]. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Sun, 2007-12-09 at 21:47 -0500, Mathieu Bouchard wrote: > On Sun, 9 Dec 2007, Jamie Bullock wrote: > > > Then I persuaded him that passing the queries as a list to the inlet > > would be more flexible. It also greatly reduces the number of objects > > required to send a query, if you have more than one query. > > I don't understand the latter part. How does it work? I'm talking about > putting any number of queries together in a single object and passing the > arguments of those queries all together in a list. How can you reduce the > number of objects more than that? The way you are suggesting always requires at least 2 objects per query: an object to build the query and a message to send it. So if you have 5 different queries (I mean with different statements not just different data), then you would need at least 10 objects. This would be the case even if there was no variable data in the queries. Using the [psql] way of doing things, provided that the queries have no variable atoms, only 6 objects would be required, one for the database connection, and 5 containing the queries, which when passed to the connection object also trigger the sending. > Your way takes at least two objects > instead of one and it does not provide any protection against SQL > injection because it can't distinguish between a symbol passed as a SQL > argument and a symbol representing part of the statement syntax itself. True, this is a good argument for the [expr]-style SQL object. Although there may be other ways to provide some protection against injection like allowing the user to lock the number of statements in the query. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Sun, 2007-12-09 at 16:47 -0500, Hans-Christoph Steiner wrote: > The "addcomma", "addsemi", "adddollar" messages are a workaround, for > sure, but yeah, I suppose a more pd-ish one. I think that if SQL > gets submitted only on the right/cold inlet, then we would not need > those messages. They might come in handy though, so they could be > added later. I think we would still need 'addsemi' to act as a statement delimiter as you showed in the subpatch of your example. > "bang" for submit sounds good too. > > As for clever hacks, I can't think of any with regexs too. Plus from > my experience, clever hacks can often lead to really strange and > difficult bugs. IMHO, we'd better off with something simple that > might be a bit harder to start on, but doesn't have odd conditions > that could trigger bugs. I agree. I don't much like the idea of maintaining a list of SQL statements for use in regex matches! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote: > > This almost *never* happens. As long as what you do in Pd is regular > read-write activities involving tables that contain data that you only > want to see a small part of at a time, you need variable atoms in almost > any query: > >select person from attendance where chatroom=? >select chatroom from attendance where person=? >select * from users where user=? >select * from chatrooms where chatroom=? > > apps more likely to have invariable queries are apps that started small, > stayed small, and will never be expanded. I take your point, but I think you are exaggerating slightly. I just looked at the code for a database driven web app I worked on recently. It uses 30 queries, 3 of which have no variables. Out of these three only one doesn't 'overlap' with other queries and therefore can't be refactored. Maybe 1 in 30 is almost never? Anyhow - I agree that I probably can't argue the case for the [psql]-style of operation on the grounds of reduced object count :-| > > True, this is a good argument for the [expr]-style SQL object. Although > > there may be other ways to provide some protection against injection > > like allowing the user to lock the number of statements in the query. > > checking the number of statements is not enough: what about a value like: > (including quotes) > >'or'1 > > put inside this statement: > >delete from users where username='$1' > > this query will delete the complete table. Good point! I think Hans' recent suggestion addresses the problem. It also occurs to me that for Postgres at least, we have the PREPARE statement, which addresses the optimisation and injection issues you have raised. Technically [psql] already supports PREPARE except that PREPARE uses the '$' character as its placeholder identifier, and '$1' can't be passed around as a symbol in Pd. I think it might be interesting to use the '?' notation currently under discussion as an interface to PREPARE though. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 09:55 -0600, Mike McGonagle wrote: > > Well, Jamie, at the same time, I think that Mathieu might be refering > how the output is handled from the 'sql' external. That is the part > that would make having just a single instance of a database object > difficult at best to work with. From some of the early tests that I > have done, I have pretty much always assumed that each instance would > be outputing a different result set. If you only used one database > object, you would have to figure out how to route all the result sets. > Fair enough, I think I was probably stretching the point about using the [psql]-style of database connectivity requiring less objects. However, it's perfectly possible to have multiple [psql] instances connected to the same database, so the routing problem is a bit of a moot point. > Could someone please explain that IMPORTANCE of worrying about SQL > injection? Just how would it effect users of PD? It is certainly important in any situation where you would want to do variable substitution on queries using data sent to your Pd instance over a network. Some people might use Pd in this way via a web interface for example. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 18:07 -0500, Hans-Christoph Steiner wrote: > > It seems many things use the "?" alone as the unnamed placeholder, but > I only saw MySQL using ?name for named placeholders. It does seem > like a nicer syntax rather than using a different character. Perhaps, > we should follow pgsql and use "$" and "$name", since "$" is already a > marker for replacement vars in Pd. I suppose that could get confusing > in something like: > > > SELECT id, ABS(($duration - $1)/$2) AS error FROM datatable ORDER BY > error LIMIT 1 > I vote that we use "?" as a placeholder, and only support unnamed placeholders. We can use this to convert to whatever the db-specific placeholder system is inside the external. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 15:00 -0500, Mathieu Bouchard wrote: > On Mon, 10 Dec 2007, Jamie Bullock wrote: > > > Fair enough, I think I was probably stretching the point about using the > > [psql]-style of database connectivity requiring less objects. > > However, it's perfectly possible to have multiple [psql] instances > > connected to the same database, so the routing problem is a bit of a > > moot point. > > But it requires multiple logins, perhaps many at once, which might be > wasteful. Not especially. > For sharing database connections between several [psql] > objects, what do you think would be the best ways to do it? This is > supposing that several different database connections can still be > used at once, as specified in the patches. > I think this is a less trivial problem than it might appear. Having a global pointer representing the database connection seems dangerous and a bit naive. Perhaps some kind of callback-based mechanism between the database connection 'server' object and the 'client' query objects would be the way to go. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 16:43 -0500, Mathieu Bouchard wrote: > On Mon, 10 Dec 2007, Mike McGonagle wrote: > > > In one of the early prototypes I wrote for this, I set it up so that the > > connections were shared. Basically, when an object tried to open a > > connection, it would check if there was already one open, and if so, it > > would use that. Else it would create a new connection, which would then > > get stored in the global connection object. > > I think that the first argument of [psql] could be a receive-symbol, > followed by the query itself. Then [psql] would not use the receive-symbol > to send messages to, it would look at the receiver directly, checking that > it's a [psql.connection] object, and then calling a function of that > object directly, and get called back when a response is received. This is > quite close to how [tabread] works except it inserts a [delay] before the > result. It's how [tabread] would work if it were trying to access an array > on another computer. I like this idea. What do you think about using an implicit receive-symbol, '$0-psql.1001', '$0-psql.1002' etc? Would it be possible for psql to automatically discover the psql.conn's receive symbol by using pd_findbyclass(), and then reading a variable in the object struct? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 10:39 +0100, Frank Barknecht wrote: > Hallo, > Thomas Grill hat gesagt: // Thomas Grill wrote: > > > it's unfortunate that you are not thrilled using flext. > > Since flext uses the PD api to get lists or other messages into > > secondary inlets there's nothing to stop you from doing the same in > > psql. The magic words are "proxy objects" which you might find in the > > mailing list archive (or the flext source code, if you prefer that). > > Needless to say flext saves you from coding these things yourself in a > > time consuming manner and makes other things really easy, once you got > > it running. You could also compile pool then. > > The Python and Lua objects also support arbitrary messages on their > inlets. Both languages have DB modules for just about every DB, > compilation of these externals only has to be done only once. But as > everyone knows that I don't really understand why a DB external has to > be a C/C++ external, I'll better be quiet now. ;) Actually, please don't be quiet! When this was discussed some time ago, you mentioned Python as a solution, and my feeling was that if I write a piece and it uses some database connectivity, I don't really want to have to distribute a Python runtime, relevant Python SQL module, [py] and all the respective dependencies with it. I just (at most) want to include an external, and the databse library it uses. If I write a piece, I can't reasonably expect a performer to resolve all of this themselves - it needs to "just work". I also want to minimise as much as possible the number of discrete components in the system that could possibly go wrong. However, Lua seems a slightly different story, ([lua] doesn't require flext, and Lua is very lean) - I'm starting to be convinced by it. It might be interesting to recreate [psql] using lua and luasql, and see how it measures up in terms of portability, ease of distribution and performance. I just downloaded [lua], and luasql, and It certainly didn't take long to get these things working on a basic level. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor time scaling
On Sun, 2007-12-09 at 18:53 +0100, Frank Barknecht wrote:
>
> Suppose I have a phasor with period p1 (and thus freq=1/p1) and I want
> to generate a signal with p2 = 1.5 * p1. Then I have (at least) two
> ways to do this ("|" should indicate the jumps):
>
> p1: |.|.|.|.|.|
>
> p2a: ||||
> p2b: ..||||
>
> Turn p1 and p2 around and you get a similar situation for trying to
> generate a phasor with a frequency of 1.5 times the original
> frequency:
>
> p2: ||||
>
> p1a: |.|.|.|.|.|
> p1b: ...|.|.|.|.|.|
>
> I suppose, you don't really care which sync point to use, only that
> both phasors sync at the least common multiple of their periods,
> right? That's where I suggested to use an additional phasor with a
> period of the LCM of the phasor signals you'd like to achieve in the
> end, and sync to that. (As the LCM of two numbers generally is larger
> than the single numbers, that phasor~ would be slower.)
Ah, now I see what you're getting at. I think this is the solution I
will probably go for, although I'm still curious to know how [rate~]
works in Max/MSP. Maybe something along the lines of Cyrille's
soluton...
Jamie
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor time scaling
Hi Cyrille, Thanks for the reply - very interesting! On Sun, 2007-12-09 at 23:08 +0100, cyrille henry wrote: > >> i think if the input can only be a phasor you can : > >> -differenciate the phasor (with a biquad: out(t) = in(t) - in(t-1) ) > >> -ignore negative value (with a test on a expr~ object by exemple) > >> -multiply by scale factor > >> -integrated this value (with a biquad: out(t) = in(t) + out(t-1) ) > >> -wrap the result > > > > I tested this (attached) and it kind of works, but it doesn't seem to > > be phase synced, so one could just as well use a second phasor~. Or > > did I do something wrong? > > > well, the max~ 0 is not the perfect way to remove negative value. it would be > beter to replace the negative value with the previus value. Are you saying that if one replaced the negative value with the previous value, the phasors _would_ be phase synced? It would certainly be possible to do this if I implemented it as an external. > if you want exactly f1/f2 = 1.5, then you can use a lower frequency phasor > and generated 2 phasor at 2f and 3f. so phasor 2 frequency / phasor 3 will be > a 1.5. In the short term, this 'low frequency master phasor' solution is the one I will go for, but it would be nice to make a generic phase-synchronous phasor rate scalor at some point. Maybe it isn't possible, but I'm sure it is what Max/MSP's rate does. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Tue, 2007-12-11 at 15:48 -0500, Hans-Christoph Steiner wrote: > On Dec 11, 2007, at 3:59 AM, Jamie Bullock wrote: > > > > > On Mon, 2007-12-10 at 18:07 -0500, Hans-Christoph Steiner wrote: > >> > > > >> It seems many things use the "?" alone as the unnamed placeholder, > >> but > >> I only saw MySQL using ?name for named placeholders. It does seem > >> like a nicer syntax rather than using a different character. > >> Perhaps, > >> we should follow pgsql and use "$" and "$name", since "$" is > >> already a > >> marker for replacement vars in Pd. I suppose that could get > >> confusing > >> in something like: > >> > >> > >> SELECT id, ABS(($duration - $1)/$2) AS error FROM datatable ORDER BY > >> error LIMIT 1 > >> > > > > I vote that we use "?" as a placeholder, and only support unnamed > > placeholders. We can use this to convert to whatever the db-specific > > placeholder system is inside the external. > > I am ok with using ?name for placeholders, but I think we should also > support the plain ? with the list input. I am fine if that happens > later tho. I'd like to get something working soon, we've done a lot > of talking :). > I agree about getting on with it. However, I probably won't be able to commit any coding time to [psql] until after Christmas. This might be sensible though - I suggest we get the interface to one of the objects 'right' first and then copy this in the others. Mike seems to be pretty active on the SQLite one, so I suggest we let that take the lead and follow that. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] What exactly is a "stack overflow" ?
On Mon, 2007-12-17 at 19:44 +, Martin Peach wrote: > In pd it usually means you have a loop somewhere, so that the output of an > object is feeding its own input: each time a new output is calculated a new > input is generated, so the process never ends and eventually the stack > overflows. AFAICT in most cases the stack doesn't actually overflow. If the message "stack overflow" gets posted to the Pd console it means that pd has prevented a stack overflow by monitoring the recursion depth, and stopping the message graph at a given outlet. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] What exactly is a "stack overflow" ?
On Thu, 2007-12-20 at 00:15 +, Andy Farnell wrote:
> Perhaps we can reach a reasonable compromise in source.
> If you knew that an accidentally banged until would give up
> after a couple of minutes it wouldn't be so bad.
IMO [until] should just not hang Pd that's all. I don't think that a
warning should be thrown when you do |bang( -> [until], or that it
should have a built in limit.
This is in the same sense that you don't get a warning when you do
'while 1:' in Python or while(1){ } or whatever in other languages.
'while 1:' doesn't hang the interpreter (at least not in the Python
implementation I use), and |bang( -> [until] shouldn't hang Pd.
Actually on my machine |bang( -> [until] runs at ~99% CPU and hangs Pd,
'while 1:' in Python runs at more like 69% and is interruptible with
ctrl-c leaving you back in the interactive interpreter unscathed.
Perhaps a usleep() is in order on each iteration?
Jamie
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] What exactly is a "stack overflow" ?
On Wed, 2007-12-19 at 18:10 -0600, Russell Bryant wrote:
>
> Furthermore, if this loop is eating up CPU and making the system unresponsive,
> you can make the situation much better by adding a simple sleep that makes the
> process yield to to other waiting processes on each iteration of the loop.
> The
> new version would look like:
>
> static void until_bang(t_until *x)
> {
> x->x_run = 1;
> x->x_count = -1;
> while (x->x_run && x->x_count) {
> x->x_count--;
> outlet_bang(x->x_obj.ob_outlet);
> usleep(1);
> }
> }
I think this is the best idea. But after writing my last post to the
list, I started to wonder if Miller had a good reason for not doing this
when he wrote the original code?
Jamie
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] What exactly is a "stack overflow" ?
On Thu, 2007-12-20 at 13:12 -0600, Mike McGonagle wrote: > > > On Dec 20, 2007 10:41 AM, Russell Bryant <[EMAIL PROTECTED]> > wrote: > So, after going through my own mental exercise to analyze the > situation, I now > > don't think any changes should be made at all. > > > I agree with this. This is just one of the few (or more) things you > need to know about when dealing with PD. It even says it on the help > page for [until]... > > > I don't think I want the software to try and second guess what I want, > and if I construct an [until] that is an infinite loop, then so be > it... > I agree, but it would be nice if there was a distinction between hanging a patch and hanging Pd. The user should at least have the opportunity to close the window that contains the infinitely looping [until], and keep Pd running. However, I don't think this would be possible without some architectural changes to Pd (like more extensive use of threading). Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] What exactly is a "stack overflow" ?
On Thu, 2007-12-20 at 16:14 -0500, Mathieu Bouchard wrote: > This is still way too much, but it's too complicated to get pd to support > interrupting its own calculations unless all externals are compiled with > C++ exception support, and even then, it's tricky because you can't > directly add exception support to libc itself or whatever else. > How do the ruby (irb) and python interactive interpreters handle this? Both python's "while 1:" and ruby's "while(1)" can be safely interrupted with ctrl-c with the interpreter still running. Would it be necessary to implement the measures you suggest above in order to implement something like this for Pd or dd - ctrl-c stops message processing? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Seasons Greetings
Wonderful! Have a great Christmas. Jamie On Fri, 2007-12-21 at 18:41 +, Andy Farnell wrote: > The time is almost upon us to to erase those brain cells > collected over the last 12 months. But who will dare post > first in the obligatory ASCII xmas tree thread? > > Mine's in Pd this year, > > Wishing you all much fun and happiness in the New Year, > > Andy > > ___ > 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] text based pd patching
On Mon, 2008-01-07 at 14:05 +, alex wrote: > Hi pders > > Here's a way of PD patching in plaintext: > Like all of your stuff, very cool! Any plans to convert the other way as well? graphical pd patch -> ascii-art patch... Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] about fiddle~
Hi, On Fri, 2008-01-11 at 13:57 +0100, matteo sisti sette wrote: > Another question about fiddle. > I'd like to be able to distinguish between a signal with a pitch and a > signal without a picth. It seems to me that fiddle always outputs its > "best guess" no matter how reliable it is. Actually that's not quite true. fiddle~ doesn't output anything at all from its first outlet unless it's pretty certain a pitch has been found. However, it does continuously output the first estimated peak location it uses to make its pitch calculation from its third outlet. It will also output 0 as a peak location if it can't find a peak, so you can make a pitched vs unpitched certainty estimator like the one in the attached patch giving 3 certainty levels (0.5 is unsure). > I thought I may use the third outlet and evaluate whether it outputs a > very randomly-varying number; however, with a [noise~] as input, it > mostly outputs values between 90 and 110 and some 0 every once in a > while. With the default fiddle~ settings, it seems to output 0 about 15% of the time, which seems quite a lot to me. Anyhow, I think this is a case of using the wrong tool for the job. Pitch/f0 estimators (PDAs) are designed to find pitch in a signal, not to measure noisiness. There are other tools to measure this - I find spectral irregularity to be quite a good noisiness metric, but there are several others. If you are interested in this, perhaps take a look at the libxtract feature extraction library, which comes with PD external that wraps its functionality. Jamie -- www.postlude.co.uk #N canvas 561 209 560 371 10; #X obj 166 36 noise~; #X obj 168 99 fiddle~; #X obj 222 35 osc~ 440; #X obj 203 142 sel 0; #X obj 230 165 t b; #X msg 230 192 0.5; #X msg 203 165 0; #X msg 168 166 1; #X obj 168 140 t b; #X obj 153 219 f; #X obj 153 288 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 153 245 sel 1 0.5 0; #X obj 174 287 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 195 287 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 -1; #X obj 223 68 *~ 0; #X obj 167 69 *~ 0; #X obj 352 32 hsl 128 15 0 1 0 0 empty noisiness empty -2 -6 0 10 -262144 -1 -1 12700 1; #X obj 99 142 tgl 15 0 empty metro-start empty 0 -6 0 10 -262144 -1 -1 1 1; #X obj 100 165 metro 20; #X text 363 14 pitch <-> noise; #X text 134 307 pitch <-> noise; #X obj 1 32 loadbang; #N canvas 3 50 141 300 invert 0; #X obj 45 86 -; #X obj 45 40 t b f; #X msg 45 64 1; #X obj 45 14 inlet; #X obj 45 121 outlet; #X connect 0 0 4 0; #X connect 1 0 2 0; #X connect 1 1 0 1; #X connect 2 0 0 0; #X connect 3 0 1 0; #X restore 349 54 pd invert; #X msg 1 64 \; pd dsp 1 \; noisiness 0.5 \; metro-start 1; #N canvas 3 50 450 300 counter 0; #X obj 338 173 + 1; #X obj 303 173 f; #X obj 303 150 t b; #X obj 303 107 inlet; #X obj 303 217 outlet; #X connect 0 0 1 1; #X connect 1 0 0 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 270 163 pd counter; #N canvas 6 75 450 300 counter 0; #X obj 338 173 + 1; #X obj 303 173 f; #X obj 303 150 t b; #X obj 303 107 inlet; #X obj 303 217 outlet; #X connect 0 0 1 1; #X connect 1 0 0 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 343 164 pd counter; #X obj 270 216 /; #X floatatom 373 201 5 0 0 0 - - -; #X floatatom 326 202 5 0 0 0 - - -; #X obj 270 244 * 100; #X floatatom 270 287 5 0 0 0 - - -; #X text 311 286 % definitely noise; #X connect 0 0 15 0; #X connect 1 0 8 0; #X connect 1 2 3 0; #X connect 1 2 25 0; #X connect 2 0 14 0; #X connect 3 0 6 0; #X connect 3 0 24 0; #X connect 3 1 4 0; #X connect 4 0 5 0; #X connect 5 0 9 1; #X connect 6 0 9 1; #X connect 7 0 9 1; #X connect 8 0 7 0; #X connect 9 0 11 0; #X connect 11 0 10 0; #X connect 11 1 12 0; #X connect 11 2 13 0; #X connect 14 0 1 0; #X connect 15 0 1 0; #X connect 16 0 15 1; #X connect 16 0 22 0; #X connect 17 0 18 0; #X connect 18 0 9 0; #X connect 21 0 23 0; #X connect 22 0 14 1; #X connect 24 0 26 0; #X connect 24 0 28 0; #X connect 25 0 26 1; #X connect 25 0 27 0; #X connect 26 0 29 0; #X connect 29 0 30 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] about fiddle~
On Fri, 2008-01-11 at 18:30 +0100, Matteo Sisti Sette wrote:
>
> > With the default fiddle~ settings, it seems to output 0 about 15% of the
> > time, which seems quite a lot to me.
>
> With pure noise as an input? Quite a lot?
> IF it is supposed to output 0 when it can't find a pitch, I would expect to
> output 0 about 90% of the time with pure noise as input!!
The thing is that fiddle~'s Maximum Liklihood pitch detector, like most
other PDAs takes a relatively small 'window' of sample data and tries to
find periodicity in it. It doesn't care about anything else.
Most small 'windows' taken from noise generators have some discernable
periodicity. There are two important things about this i) the very fact
of windowing the signal imposes an artificial periodicity on it, ii) any
PDA based on an FFT/STFT assumes that the windowed signal is periodic,
because the FFT assumes this. You can try this as an experiment: take a
1024 sample of a noise wave form, and play it back with tabosc~. It will
have a disernable sense of pitch.
I said that 15% seems like quite a lot because generally speaking noise
tolerance is generally considered to be a good quality in PDAs. Given
the same test conditions as I used above, The 'f0' function in libxtract
failed to find a fundamental less than 0.5% of the time and over 5000
frames 'failsafe_f0' failed 0% of the time. However, these functions are
a _lot_ less efficient than fiddle~ and have different design goals.
>
> > Anyhow, I think this is a case of using the wrong tool for the job.
> > Pitch/f0 estimators (PDAs) are designed to find pitch in a signal, not
> > to measure noisiness. There are other tools to measure this
>
> Maybe. The fact is that I do want to find a pitch, but I consider "none" as
> a possible value, i.e. I want to find the pitch if the signal reasonably has
> one, and ignore it when it is most probably garbage.
I think that's reasonable. Both 'f0' and 'failsafe_f0' give their output
on a block-by-block basis, and will give '0' if they can't find a pitch.
In addition the function have a return code that indicates whether the
function has failed or succeeded, but this isn't accessible from the Pd
extern.
> I thought there were two kinds of pitch trackers: those which do have a
> "none" value, and those which assume a pitch must exist and output their
> best estimation always. (well and a "fuzzy" third type, which always give
> both a pitch value and an estimated reliability value).
I think the estimated reliability is quite difficult. But should be
possible if another metric is used in combination with f0.
> How do you measure (or define) spectral irregularity?
There are two definitions, one by Krimphoff (1994), and one by Jensen
(1999).
In Latex maths code:
Krimphoff:
Irregularity = \sum_{k=2}^{N-1} |a_k - \frac{a_{k-1} + a_k + a_{k+1}}
{3}|
Jensen:
Irregularity = \frac{\sum_{k=1}^{N} (a_k - a_{k+1})} {\sum_{k=1}^N
a_k^2}
>
> I may want to use spectral irregularity to estimate whether the signal is
> non-noisy and then use fiddle to get the pitch when it is supposed to exist;
> I just thought that nobody better than the pitchtracker itself could tell me
> how difficult it is for it to find the pitch!
You might want to look at some other features as well, there is quite a
good Noisiness measure based on (I think) the spectral flatness measure
(SFM) of Bark coefficients.
Jamie
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] about fiddle~
On Fri, 2008-01-11 at 19:59 +, Jamie Bullock wrote:
> Krimphoff:
>
> Irregularity = \sum_{k=2}^{N-1} |a_k - \frac{a_{k-1} + a_k + a_{k+1}}
> {3}|
>
> Jensen:
>
> Irregularity = \frac{\sum_{k=1}^{N} (a_k - a_{k+1})} {\sum_{k=1}^N
> a_k^2}
>
Where a_k is the amplitude of the kth coefficient in the magnitude
spectrum.
Jamie
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] "Structured" dataflow?
On Fri, 2008-01-11 at 11:29 -0800, Dudley Brooks wrote: > Can anyone direct me to articles on constructing clear, modular, > non-spaghetti patches in pd or other visual dataflow languages? > Especially if the articles derive their recommendations from theoretical > analysis (as with the investigations that led to structured programming > in imperative languages), rather than just rules-of-thumb -- although > the latter are useful also. You might find this document interesting if not helpful: http://dspace.mit.edu/handle/1721.1/13474 > Or is some amount of spaghetti unavoidable in dataflow languages, > perhaps because it is inherent in the situation being modeled, rather > than being an artifact of the language? Personally, I find that there is an idiomatic way to use most languages, which is congruous with the way the language is designed. Of course, people may want to deliberately subvert this relationship, but I guess that's different from using something in an unidiomatic way and not being aware of the fact. Although, I think Frank wrote these in a non-didactic spirit, I find Franks 'dogmas' very helpful for clear and idiomatic Pd patching: http://lists.puredata.info/pipermail/pd-list/2007-04/049447.html I have also found Frank's 'footils' collection of abstractions to be an excellent source of idioms and examples of how to make clear and coherent patches. I must stress that I'm not suggesting that this is the 'correct' way to patch, I just personally find it to be clear, elegant and spaghetti avoiding! best, Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] text based pd patching
On Sat, 2008-01-12 at 13:50 +0100, Andre Schmidt wrote: > yup, > > very nice and usefull in (non-html) emails, console, man pages and so on > (where you only can display text)... but for pdf, webbrowser i would > prefer svg. as its also just text (therefor searchable, but dunno if > in > pdf) and looks "better" (propably exactly like in pd) than ascii... > > i would love to do a pd-patch to svg converter, but theres no info > about > the inlets/outlets in pd-patches. so we would need to have pd on the > webserver to convert pd-patches to svg... > Have you looked at the application pstoedit? http://www.pstoedit.net/pstoedit With that it's possible to save a patch as postscript using Pd's 'print' option from the file menu and then: pstoedit -f plot-svg pd.ps pd.svg Gives you a Pd patch as SVG! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] questions for everibody...
On Sun, 2008-01-13 at 12:35 +0100, David Schaffer wrote: > A little poll: > > -According to you, what is THE feature/fonction/object that Pd misses > the most? A formal dynamic patching interface. I would like what is possible in Chuck and SuperCollider with regard to dynamic instantiation and destruction of objects to be possible in Pd, implemented in a stable way with a consistent Pd-like interface. > -What Pd feature/fonction/object causes you the most problems? The lack of 'helper' functionality for visual layout. I waste way too much time moving objects around to get them lined up and looking good. Some basic options like 'snap to grid', horizontal and vertical alignments, and 'distribute centres' for selected objects would be nice. Also useful would be the ability to apply operations on selected objects like setting vertical and horizontal dimensions of groups of sliders in one shot would save a lot of time. Out of interest what are you going to use this info for, or is just for interest? Jamie > -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Max's [!/] as a Pd abstraction
Hi folks, This is ultra-simple, but I find it so useful that I thought I'd make it available. Basically it's an abstraction that provides functionality equivalent to Max's [!/], [!-] etc. With these objects the inlets are in the opposite order to the operands. The pd abstraction is essentially syntactic sugar, so instead of doing: |0.4( | [t b a] |/ |1( / | / [- ] You can just do: |0.4( | [! - 1] Probably someone has already done this and made it available, but here it is anyhow: http://puredata.info/Members/jb/exclamation-mark/view Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Max's [!/] as a Pd abstraction
On Sun, 2008-01-13 at 17:17 +, Jamie Bullock wrote: > The pd abstraction is essentially > syntactic sugar, so instead of doing: > > |0.4( > | > [t b a] > |/ > |1( / > | / > [- ] > > You can just do: > > |0.4( > | > [! - 1] As someone just pointed out to me, this is also syntactic sugar for the leaner: [0.4( | [swap 1] \ / [- ] Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] LADSPA plugin problem
On Fri, 2008-01-18 at 00:55 +0100, Derek Holzer wrote: > Hi Andy, > > Andy Farnell wrote: > > For some strange reason [plugin~] has stopped responding > > to [print( messages. I'm sure this used to work before but now > > I get "no method for print". Any ideas anyone? > > Try [list( or [help(, I don't remember which does something. It's |listplugins( If you can't get [plugin~] to work try [dssi~], which also has more functionality. Also don't forget that the plugin list is sent to the left-most outlet as a list of lists, not straight to the Pd console, so you'll need to hook up a [print]. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] spectral irregularity to measure noisiness (was Re: about fiddle~)
On Fri, 2008-01-18 at 15:47 +0100, matteo sisti sette wrote: > Thank you very much :) > > By the way, I have just tried Spectral Flatness (as defined in > Wikipedia) and it seems promising. > > I attach an abstraction that outputs spectral flatness in PD-vanilla. That's not actually a correct implementation of spectral flatness. What you've done is more like the arithmetic mean of the log-magnitude spectrum over arithmetic mean of the mag spectrum. Whereas the SFM is the _geometric_ mean of the mag spectrum over over its arithmetic mean. The problem is that in order to obtain the geometric mean, you need to ignore bins containing 0, otherwise you will get an overall value of 0 if there are '0 bins' present. See attached for a more 'correct' implementation. There is also an external that implements SFM in the CVS: http://pure-data.cvs.sourceforge.net/pure-data/externals/postlude/flib/src/ See sfm~.c However, the flib library in general is deprecated, and libxtract should be used instead. At any rate, both of the Pd implementations using [fexpr~] are horribly inefficient, and SFM is inefficient to compute at the best of times because it requires at least two iterations over the the input vector. That's why I recommended Irregularity. It tells you roughly the same thing, but is a nicer feature in terms of computation cost, and things like avoiding NaNs and infs. Jamie -- www.postlude.co.uk #N canvas 571 170 686 626 12; #X obj 35 49 inlet~; #X obj 26 148 *~; #X obj 66 148 *~; #X obj 26 189 sqrt~; #X obj 24 392 snapshot~; #X obj 192 393 snapshot~; #X obj 192 426 / \$1; #X obj 125 517 /; #X obj 179 162 t b b b; #X obj 174 103 bang~; #X obj 121 594 outlet; #X msg 116 194 clear; #X text 292 23 \$1: block size; #X obj 111 392 loadbang; #X obj 111 420 f \$1; #X obj 111 445 swap 1; #X obj 121 480 /; #X obj 295 82 block~ \$1; #X obj 35 101 fft~; #X obj 26 317 fexpr~ if($x > 0 && $x[-1] > 0 \, $x[-1] * $x \, 0); #X obj 37 425 pow; #X obj 124 556 expr 10 * log10($f1); #X obj 419 318 fexpr~ $x[-1]+$x; #X connect 0 0 18 0; #X connect 1 0 3 0; #X connect 2 0 3 0; #X connect 3 0 19 0; #X connect 3 0 22 0; #X connect 4 0 20 0; #X connect 5 0 6 0; #X connect 6 0 7 1; #X connect 7 0 21 0; #X connect 8 0 11 0; #X connect 8 1 4 0; #X connect 8 2 5 0; #X connect 9 0 8 0; #X connect 11 0 19 0; #X connect 11 0 22 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 15 1 16 1; #X connect 16 0 20 1; #X connect 18 0 1 0; #X connect 18 0 1 1; #X connect 18 1 2 0; #X connect 18 1 2 1; #X connect 19 0 4 0; #X connect 20 0 7 0; #X connect 21 0 10 0; #X connect 22 0 5 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] spectral irregularity to measure noisiness (was Re: about fiddle~)
Hi,
On Fri, 2008-01-18 at 14:04 +0100, matteo sisti sette wrote:
> Jamie Bullock wrote:
>
> > I find spectral irregularity to be quite a good noisiness metric,
> > [...]
> > Krimphoff:
> > Irregularity = \sum_{k=2}^{N-1} |a_k - \frac{a_{k-1} + a_k + a_{k+1}}{3}|
> > Jensen:
> > Irregularity = \frac{\sum_{k=1}^{N} (a_k - a_{k+1})} {\sum_{k=1}^Na_k^2}
> > [...]
> > Where a_k is the amplitude of the kth coefficient in the magnitude spectrum.
>
> I googled a little bit, and as far as I understand, these definitions
> seem to apply to an harmonic sound, and a_k seems to be the amplitude
> of the k-th partial... that is the sound is supposed to be pitch and
> its spectral peaks (partials) have already been extracted...
The irregularity metric is generally computed on the magnitude spectrum,
but there is no reason not use it on the harmonic spectrum, as some
authors do. It is just giving you a measure of the 'jaggedness' of a
given sequence of numbers, you could use it on any distribution, e.g.
you could take the irregularity measure of the numbers of Pd mailing
list postings over a 12 month period!
For the purposes of computing noise content it makes sense to use the
mag spectrum. Some authors e.g. Park (2004) use the log magnitude
spectrum.
> Would it make any sense to apply the above formulas using just the
> magnitude spectrum coefficients of the whole spectrum as a_k??
> If so, I'm not sure whether a high irregularity should be expected to
> correspond to a high or low noisiness.
It depends which formula you use. Using Krimphoff ('Irregularity I' in
libxtract), a high irregularity value corresponds to high noise content.
The relationship is approximately inverted if you use Jensen.
I performed an analysis in Sonic Visualiser using a sound that contains
a linear crossfade between a 440Hz sine wave and white noise. The
results can be found at:
http://www.postlude.co.uk/incoming/sine-noise/sine-noise.png
The red line shows Irregularity calculated via Krimphoff's method, the
blue line shows Jensen.
The audio file I used is at:
http://www.postlude.co.uk/incoming/sine-noise/sine-noise.wav
Jamie
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] spectral irregularity to measure noisiness (was Re:about fiddle~)
On Fri, 2008-01-18 at 18:48 +0100, Matteo Sisti Sette wrote: > > That's not actually a correct implementation of spectral flatness. What > > you've done is more like the arithmetic mean of the log-magnitude > > spectrum over arithmetic mean of the mag spectrum. Whereas the SFM is > > the _geometric_ mean of the mag spectrum over over its arithmetic mean. > > Isn't the arithmetic mean of the log-magnitude equivalent to the log of the > geometric mean of the magnitude? so if you reverse the logarithm after > calculating it, as I did in my attachment, you obtain the geometric mean of > the magnitude. Actually, you're right! ... and that's a cool technique! > I think this is the only way of calculating the geometric mean of such a > large vector (or isn't it?), because actually computing the product would > soon overflow the precision of a float giving either +INF or zero (even with > no zero bin) (I had tried that first). Also true. That's why libxtract uses double precision for the SFM calculation, and why flib is deprecated ;-) I just tested libxtract spectral_flatness() against your abstraction, and the output is roughly the same. Even though it uses doubles, the lx version definitely loses some precision. It's approximately twice as fast though. > Also, I may be missing something, but I think your attached patch only > calculates the product and sum of the LAST TWO bins. Note you use > [fexpr~ $x[0]+$x[-1]] and [fexpr~ $x[0]*$x[-1]] > where I would use: > [fexpr~ $x[0]+$y[-1]] and [fexpr~ $x[0]*$y[-1]] Erm... forget it. I never could the hang of fexpr~ ;-) > > > The problem is that in order to obtain the geometric mean, you need to > > ignore bins containing 0, otherwise you will get an overall value of 0 > > if there are '0 bins' present. > > Yeah here you are right. I didn't take care of that. > Well, no, wait... I did. Using [rmstodb~]-100 for the log calculation, a 0 > bin would be clipped to a -100 log value, thus being computed as a very very > small but nonzero bin. > Not sure it is the most correct thing to do, but it kinda works. I can't think of any major flaws in this method. > > > At any rate, both of the Pd implementations using [fexpr~] are horribly > > inefficient, > > So horribly? I got a 4-5% CPU usage, which may be very much but I don't need > to apply it to more than two or three signals. Well if it works for you then that's fine. I don't believe in optimising things for speed just for the sake of it. On my machine I get 5-8% load for your abstraction, and 2-4% load for xtract~, but if there's no problem, you certainly don't want to got the trouble of installing a library, and an external just for one feature! > > That's why I recommended Irregularity. It tells you roughly the same > > thing, but is a nicer feature in terms of computation cost, > > I'll try that out and make some comparisons. > > However having a look at the formulas (if again i'm not missing something), > it seems to me that it should have a similar computation cost: you still > need to iterate over the vector, don't you? Actually you're right. I was thinking in terms of something that did: gm = get_geometric_mean(...) am = get_arithmetic_mean(...) sfm = 10 * log10(gm / am) But libxtract doesn't do that. I just did a small benchmark, and sfm and irregularity_j are on a par, with irregularity_k about 30% slower. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] about fiddle~
This one's pretty helpful too:
@misc{ puckette98realtime,
author = "M. Puckette and T. Apel and D. Zicarelli",
title = "Real-time audio analysis tools for Pd and MSP",
text = "Puckette, M. S., T. Apel, and D. D. Zicarelli. 1998. Real-time audio
analysis
tools for Pd and MSP. Proceedings of the International Computer Music
Conference.
??-?.",
year = "1998",
url = "citeseer.ist.psu.edu/puckette98realtime.html" }
Jamie
On Thu, 2008-01-17 at 08:19 -0800, Miller Puckette wrote:
> I don't know if this helps, but I wrote a paper, "score following using the
> sung voice" that has some info on that:
>
> http://crca.ucsd.edu/~msp/Publications//icmc95.ps
>
> cheers
> Miller
>
> On Thu, Jan 17, 2008 at 04:06:59PM +0100, matteo sisti sette wrote:
> > First of all thanks to everybody for the clarifications and
> > suggestions I received.
> >
> >
> > 2008/1/11, Miller Puckette <[EMAIL PROTECTED]>:
> >
> > > I don't know any canonical way to decide when a note is finished, except
> > > to notice that a new note has started.
> >
> > That's very interesting: it reveals to me how wrong my way of
> > conceiving the whole thing from the beginning is.
> >
> > I still can't understand too well how it works. I mean, apart from
> > what I was trying to do and no matter whether fiddle is or isn't
> > possibly useful for doing that, I am now simply trying to understand
> > just how fiddle works.
> >
> > My idea of "understanding" is being able to predict the expected (or
> > ideal) behaviour of fiddle in response to a given input.
> >
> > For example, how should I expect it to behave if I send it a phasor
> > (to say a non-sinusoidal but clean-pitched sound) with a pitch that
> > increases slowly but steadily up to several semitones or even octaves?
> > What if the same increase in pitch is much faster? How do the
> > "vibrato" parameters influence?
> > Another example: what about re-attacks? When should I expect a
> > repetition of the same note to appear as a repeated pitch on the
> > cooked-pitch (first) outlet, and when should I instead expect only a
> > bang in the attack outlet?
> >
> > Is all this kind of things explained in detail somewhere?
> > Maybe all or part of this is not specifical to Fiddle but generar
> > pitchtracking theory stuff?
> >
> > Or do I have to look at the source code? :scared:
> >
> > I did try to play with it and observe in order to find some answers,
> > but I'm too lost to be able to draw conclusions from tests (too many
> > mutually interfering questions).
> >
> >
> > By the way, I had a look at the examples mentioned by Hans Roels (I
> > only found example patches, no plain explanations) but I'm afraid my
> > uncertainties are at a deeper level.
> >
> > Thanks again
> > m.
> >
> > --
> > Matteo Sisti Sette
> > [EMAIL PROTECTED]
> > http://www.matteosistisette.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
--
www.postlude.co.uk
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor to square
On Mon, 2008-01-21 at 11:43 +0100, raul diaz wrote: > Hi Frank, list! > > Thanks for your suggestion about Miller's documentation, very useful! > I have taken a look to your [vosim] abstraction, very nice! > There is any abstraction with an implementation of fof synthesis? > I would like to play with vosim and fof techniques and compare both. There is a PAF (phase aligned formant) synthesis example in the Pd documentation (F.12 and F.13). PAF is related to, but not exactly the same as FOF (http://www.ircam.fr/288.html?&tx_ircam_pi2%5BshowUid% 5D=34&cHash=016189f3fb&L=1) although other than the implementation, I'm not exactly sure what the difference is. Anyone know? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] FOSS audio tools (was: sound for blender apricot opensource game)
On Sun, 2008-02-03 at 12:51 +0100, Roman Haefeli wrote: > OTOH, LADSPA plugins don't > support customized guis, AFAIK, therefor there is no option to do > something like jamin as a LADSPA plugin. IMHO, most LADSPA plugins might > be good scientific applications, but definitely not for everyday studio > work (no visual feedback, strange scales of parameters). But of course customised GUIs have been available via DSSI (an extension of LADSPA) since 2004, and LV2 (LADSPA version 2) now provides infrastructure for GUIs, units etc. (http://lv2plug.in/) Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] smoothing control signals
On Fri, 2008-02-08 at 22:43 +, matthew venn wrote: > I'm sure I must have missed an obvious external or patch somewhere, as > it seems to me like quite a useful function. I think [mavg] from the zexy library does what you want. zexy is included with Pd-extended. If you are on Linux another easy way to get it might be through your package manager (depending on which distro you use). Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] *.lua => *.pd_lua or *.l_lua?
Hi, On Sun, 2008-02-10 at 14:03 +0100, Frank Barknecht wrote: > I'm thinking if a custom file extension for pdlua classes would make > sense? Currently pdlua loads all *.lua files, which complicates > working with *.lua modules not intended to be used as pd classes: > Those would have to be in a directory outside of Pd's search path to > not pollute Pd's namespace. > > So my suggestion would be to use something like *.pd_lua, *.pdlua or > *.l_lua as extension. What do you think? The same question may become > an issue for other loaders as well, so a standard solution would be > nice. How about *.pd.lua? This has the advantage keeping the standard .lua extension whilst providing a standardised suffix which indicates that this is a special Pd Lua script... Just a thought. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pitchshifter object?
On Mon, 2008-02-11 at 00:23 -0500, Kevin McCoy wrote: > The rubber band library sounds pretty good to me - has anyone made an > external for this? > > http://breakfastquay.com/rubberband/ > It might not be necessary to make an external since there is already a couple of LADSPA plugins available that wrap the rubberband functionality. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] measurement of spectral richness
Hi, On Tue, 2008-02-12 at 13:45 -0800, punchik punchik wrote: > ive heard a lot of times that natural sounds has more > spectral richness that digital generated sounds... > is it possible to measure the spectral richness of a > sound? There isn't a standard metric for 'richness' as far as I know. However, you might be able to break down the 'richness' percept into a number of features that can be measured. Things that spring to mind as contributing to perceived richness are: - The number of measured partials - The 'inharmonicity' of the spectrum (i.e. its divergence from a purely harmonic signal) - The 'spectral flux' the amount of variation (transience) in the spectrum between frames You could try to find a mathematical relationship between these factors that corresponds to the richness percept, or you could use some kind of classifier which you would 'train' to relate a given richness input vector (npartials, inharmonicity, flux) with a perceptually determined output measure of richness. One of the simplest classifiers for this is the k-NN classifier. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] audio sample labeling... (onset, fundamental freq)
Hi, On Fri, 2008-02-15 at 22:07 +0100, Rich E wrote: > What I meant by the last sentence was that I would like to do the > annotations directly in pd, using as input an array or soundfile. > > I think sonicvisualiser uses aubio for their onset detector. Does > anyone have any opinions as to whether this is the best way to go? Frank Barknecht made a simple onset-based beat slicer using Pd and aubio. See this thread: http://lists.puredata.info/pipermail/pd-list/2006-10/043536.html If I understand your question correctly, I think you're looking for something along the lines of Nick Collins' BBCut2 (http://www.cus.cam.ac.uk/~nc272/bbcut2.html). It would be nice to have something like that in Pd, but if you want to do it properly its a non-trivial task. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ann_som users
Hi, On Mon, 2008-02-25 at 15:26 -0800, B. Bogart wrote: > Hey all, > > I just wanted to get a sense of the ann_som users out there. > > I would like to make some changes/additions, in particular: > > * Gaussian neighbourhood function to increase convergence with many sensors. > > * built in function for randomizing sensors (my network has about 4 > million weights, which is pretty anoying to use "init" for.) > > Maybe more as things move along. Nice to see someone working on this. I haven't used [ann_som] in earnest, but I have used [ann_mlp], which is great, and am generally interested in the progress of AI things in Pd. One thing it might be worth looking at is the SOM and Growing Neural Gas support that was added to the FANN library as part of GSoC last year. There is some discussion about it on this thread: http://leenissen.dk/fann/forum/viewtopic.php?t=46&start=30 The code is also the FANN CVS under the gsoc2007 branch. I did get it to compile at one point but I haven't really tested. It may be in some way informative ? Anyhow, I look forward to the [ann_som] improvements. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to get plugin~ to work on windows with LADSPA plugins?
> I'm trying to use LADSPA plugins with PD on windows... I've got the most > recent pd-extended package installed, Pd version 0.38.4-extended-RC8. > > I figure I need to tell it the path to the ladspa dlls (I'm using ones > that came with Audacity for now), and give it the correct parameters. I > copied a plugin (sc4.dll) to the pd bin folder and the extras folder, as I > expect pd/plugin~ looks in those places.. I'm afraid it's not as simple as that. [plugin~] doesn't know anything about Pd's search path. It uses the environment variable LADSPA_PATH to search for the DLL. Depending on how portable getenv() is, you might just be able to set the LADPSA_PATH on windows to the directory that contains your plugins, and then use the external exactly as you describe below. > E.g. would "plugin~ sc4 sc4.dll" be the correct thing to type to get it to > load the sc4 compressor plugin? > If that doesn't work, you should try giving the absolute path to the dll, e.g. [plugin~ sc4 c:\my\plugin\path\sc4.dll] I'm not exactly sure of the path spec that dlopen() expects on Windows, so you might need to experiment with e.g using forward slashes: c:/my/plugin/path ?? > Is it possible to use LADSPA plugins on windows? If so, I'd really > appreciate someone telling me how... if I get this working maybe I'll > update the pure-data.info wiki with the details.. It's definitely possible as evindenced by Audacity's LADSPA support. It's just a case of getting plugin~ to find and load the plugins. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] vowel recognition
On Mon, 2008-03-10 at 19:35 -0400, marius schebella wrote: > hi, > I wonder if anyone did vowel recognition with Pd. Maybe ed kelly? or > brian j.? > can it be based on fiddle~ or does it neeed more/other objects/technology? You might be able to make a crude vowel recognition system using [fiddle~] and [choice]. You could make some vowel profile vectors using the sinusoidal components from the 5th output of fiddle~, and build a database of vowel profiles in [choice], which can be matched to unknown 'candidate' vectors. If you want to do it using a more sophisticated/conventional technique, you should probably look at using MFCC or LPCC to create your feature vector, combined with a classifier such as k-NN or neural network to do the actual recognition. All of these things can be done in Pd with the help of a few externals. My libxtract library supports both MFCC and LPCC extraction and has a Pd implementation: http://sourceforge.net/projects/libxtract If you are going to use it, I would advise checking out the svn version since it includes a number of bug fixes and new features. best, Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Google Summer of Code application is in!
On Wed, 2008-03-12 at 13:09 -0400, Hans-Christoph Steiner wrote: > I just submitted it with 10 mentors, we should be able to add more > mentors if we get accepted as an organization, so it is not too late > to join. > > http://puredata.info/dev/summer-of-code/GSoCOrganizationApp2008 > > I think the app is looking good, fingers crossed! Nice work Hans. Thanks for being the "Pd ambassador"! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] GSoC Organization App 2008 wiki page
On Tue, 2008-03-18 at 15:08 -0400, Hans-Christoph Steiner wrote: > On Mar 18, 2008, at 4:30 AM, Georg Holzmann wrote: > > > Hans-Christoph Steiner schrieb: > >> I think they want to see more polish on the app. I had a brief > >> conversation with the administrator of GSoC, Leslie Hawthorn: > > > > Hm, I don't know ... > > We had really many ideas on the page and described in many details > > (at least the most of them) - much more than last year. > > Also the other organizations I was looking through did have much > > less ideas without a detailed description ... > > > > However, of course it can be better for the next time ;) > > > I think they wanted to see the whole page look polished. We had a > lot of ideas, some polished, and some just jotted down. Well at least the list is there now. Pity about the application, I was looking forward to it :-( Anyhow - had I known about the ideas needing more fleshing out I would have been happy to do so. Here's to next year's app with more flesh on the bones! BTW, I also wonder if we would have a better chance if we had some kind of already established 'Foundation' - I see this word popping up a lot on the participating organisations page. I know Pd enjoys its de-centralised status, but having some kind of semi-formal 'Foundation' seems to help with things like funding applications. What do you think? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] I'm stuck in a corner, please help! RE: [delta~] object
On Sat, 2008-03-22 at 13:34 +0100, Roman Haefeli wrote: > On Fri, 2008-03-21 at 18:38 -0400, marius schebella wrote: > > hmm, > > first, i think you need [swap 1000] instead of [swap 1], because you > > want to delay by 1000/44100 milliseconds and not 1/44100 milliseconds. > > and then, there is this problem that delwrite~/delread~ is sensitive to > > the order of creation. I attached a small patch, you can see that a > > delwrite/read that is created before the line~ object works similar to > > z~, wheras the delwrite/delread that is created after the line~ is one > > vector behind. > > I attach a patch for clarification... > > marius. > > > > > Andy Farnell wrote: > > > [rzero~] and [delwrite~] methods come out louder > > > and with apparently less dynamics. Using [z~] and [fexpr~] > > > I get much closer results to [delta~], more detail in > > > the poured water sound. > > > let me mention a clean way to solve the issue with a block delay without > having to care about creation order. have a look at the doc: > > 3.audio.examples/G05.execution.oder.pd Yes! Andy: if you can get delread~/delwrite~ to do what you want using the G05 style of execution order forcing, wouldn't that be a cleaner solution for your book? I mean this from the point of view that the expr~ family are really externals. I also think that fexpr~'s syntax is quite confusing, and might interrupt the flow of your discussion if you are the sound design concepts are to be in the 'foreground' rather than learning how to use the objects... or maybe that's just my personal (anti-expr) taste coming through ;-) Jamie -- www.postlude.co.uk ___ 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
Derek, Thanks for posting this! I've been looking around for a while for a simple, low cost HID board. The Arduino and Multio are just overkill if all you want is something you can stick a couple of pots/sensors/switches into. Jamie On Wed, 2008-03-26 at 21:18 +0100, Derek Holzer wrote: > Martin Howse just posted his documentation of a simple HID sensor board, > costing approx EUR 5 to make, which can be used over USB with PD, > SuperCollider, etc. > > http://1010.co.uk/avrhid.html > > This board was used during a sensor workshop which took place at Pickled > Feet in Berlin on 15 March 2008, with the second part taking place on 26 > April 2008. Details here: > > http://1010.co.uk/workshop.html > > Further docs could include step-by-step programming instructions, sensor > connection schematics and sample PD patches. > > Feedback more than welcome! > > best, > d. > -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] plugin~ crashing
Hi pzuspann, On Mon, 2008-03-31 at 12:24 -0700, pzuspann wrote: > I recently installed PD (from a daily build - 0.40.3-extended-20080222) on my > Intel Mac OS X (10.5.2) laptop. Pd crashes when I try to load an actual > plugin to the object plugin~. First problem is that my ladspa path is not > set-up, so I have to remedy that, but I also get a gui error which crashes > PD. Can any one offer guidance? I have lots of LADSPA plugins that I > installed with DMG packages along with ardour. (Also, I'm not sure where to > set the path to access these.) I'm new to mac, but familiar with > linux/music apps... > > Here is the contents of the console output after the crash: > > 3/31/08 3:17:55 PM [0x0-0x81081].org.puredata.pd.wish[2353] Warning: no > LADSPA_PATH, assuming /usr/lib/ladspa:/usr/local/lib/ladspa > 3/31/08 3:17:59 PM [0x0-0x81081].org.puredata.pd.wish[2353] Warning: no > LADSPA_PATH, assuming /usr/lib/ladspa:/usr/local/lib/ladspa > 3/31/08 3:18:17 PM [0x0-0x81081].org.puredata.pd.wish[2353] pd_gui: pd > process exited > > Forgive me if this post is redundant. I have searched many forums, but to no > constructive avail. If I remember correctly, the Ardour installer doesn't put the plugins under the /usr tree, but rather under /Library/Frameworks, is that the case? Do you actually have plugins in /usr/local/lib/ladspa or /usr/lib/ladspa? You said you set the environment variable, is it really set? What's the output of 'export | grep LADSPA' ? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] lillypond
On Fri, 2008-04-04 at 02:17 -0700, Jaime Oliver wrote: > Hello, > > > Does any of you know of a way of making lillypond files from pd? You could try firelily: http://percival-music.ca/firelily/ You can use it create Lilypond scores by sending it OSC messages. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sms external
Heh .. when I saw the subject I thought this was going to be about an SMS *messaging* external ;-) Jamie On Mon, 2008-04-07 at 14:17 -0400, marius schebella wrote: > hi, > some time ago someone (rich e) posted that he wanted to work on an sms > (Spectral Modeling Synthesis) external for pd > (http://lists.puredata.info/pipermail/pd-dev/2008-01/010709.html), just > curious if you're still working on it or if you come up with another > solution? thanks, > marius. > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] gem-users list ?
Hi, Does anyone (except me) think it would be a good idea to start a Gem-users list? An increasing amount of the discussion on pd-list seems to be Gem-specific. I use, and enjoy Gem, so this isn't any kind of anti-Gem thing, I just think it would be convenient from an email filtering POV if there was a list just for Gem that wasn't a 'dev' list. Just my 2p, Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Tue, 2008-04-22 at 17:23 +0200, Thomas Grill wrote: > Me for one, i have really missed pow~ or abs~ but i have been missing > many other things. > I don't see the necessity for the objects you mentioned when they can > be built as abstractions using expr~ within seconds. But isn't expr~ an external? I don't see using expr~ as a 'vanilla pd' solution to this problem. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Trax - Sinusoidal Model Synthesis in Pure Data
On Thu, 2008-04-24 at 20:34 -0700, Rich E wrote: > www.teafordragons.com/rte/trax.html > > This is a patch I've been working on for quite some time now, finally > packaged with some documentation and an example qlist with it. Trax > is a fancy additive synthesizer that stores partials in data > structures and re-synthesizes them using [oscbank~]. It gets the > sinusoidal models from SDIF files with 1TRC frames, which have to be > imported with [sdiflists]. I'd like to know how well it works for > others, it makes great sounds on my Ubuntu laptop, although I had much > worse results on a Macbook. Fantastic stuff! Thanks for sharing, i'll definitely use this. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Fri, 2008-04-25 at 11:37 -0400, marius schebella wrote: > > in max (4.6) you get > [sig~ 6] > | > [pow~ 2] > | > [snapshot~] > | > [64\ Same with cyclone/pow~ Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
On Sat, 2008-05-03 at 05:16 -0400, cdr wrote: > > I am not sure what you mean by 'chrome' though. > > http://www.37signals.com/svn/archives2/lingo_chrome.php > > to get OS chrome on Tk, it may be as simple as a 'require Tktile' http://www.catb.org/~esr/jargon/html/C/chrome.html -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN - Gesture Recognition Capabilities
Hi, On Sun, 2008-05-04 at 08:37 +0200, Georg Holzmann wrote: > > in the description of the algorithm they talk about some pending > > patents... I guess they use more than simple ann comparison to get this > > working in realtime on a game console. > > Yes, I also would not use a feedforward neural network (as implemented > in ann) for this. You have to use a model which also incorporates time. Hm. You can incorporate changes over time using a standard feedforward ANN by wrapping your time-ordered vectors over a given time period into a single input vector and increasing the number of inputs to the network accordingly. But of course this introduces latency and other problems (e.g. it could massively increase the number of training examples required). Pd has the ann_td external, which provides a 'time delay' neural network which I believe incorporates time using a method similar to that described above. > For example a hidden markov model or echo state network (= special kind > of recurrent neural network) should work. I'm intrigued! Presumably these approaches avoid the latency problem by maintaining the network's state? Are there other advantages -- easier to train? Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote: > I've never worked with that, however I'm always irritated, when > patching environments have their cord connections flow left to right > instead of top to bottom. IMO that's such a waste of space in > languages, that are written horizontally. If you look at the "Midi to > Poly" object here: http://synthmaker.co.uk/images/components%20L.png > you'll see that most of it is just an empty grey rectangle, whose > width is just there to make room for the object name. If the > in/outlets were top and bottom as in Pd and Max, the box could be much > smaller without losing any information. I agree. However, I'm quite warming to chord-less patching a la circle: http://www.futureaudioworkshop.com/ IMO, this looks like a really nice and well-thought-through UI. Although I am definitely not suggesting Pd should go down that route -- Pd and Circle are two very different beasts! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Trax - Sinusoidal Model Synthesis in Pure Data
On Mon, 2008-04-28 at 11:32 -0700, Rich E wrote: > Wait until I get libsms up and running in real-time... tons of doors, > all leading to different places. There's lots of things I wanted to > do with Trax, but it just isn't feasible using pd's control structure > and the data structs alone, it seems much better to do the low-level > stuff it in C and use pd as a controller. I don't like having to > graph everything using Tk either, so that part will probably be moved > to opengl somehow. All in due time. > I can't wait! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Non-transposing delay
Hi folks, Does anyone know of Pd implemenation (or external) of a non-transposing variable delay? Thanks, Jamie -- www.postlude.co.uk Birmingham City University is the new name unveiled for the former University of Central England in Birmingham For more information about the name change go to http://www.bcu.ac.uk/namechange/official_announcement.html ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Non-transposing delay
On Thu, 2008-06-05 at 19:22 +0200, Luigi Rensinghoff wrote: > Hi > > > what about vd~ ?? Is it not what you are looking for ? > > > Or is "non-transposing-delay" any kind of special term i dont know > of ?? By 'non-transposing' I mean that the pitch of the delayed signal doesn't get changed as a byproduct of the dynamic change in delay time. Anyhow, I managed to work something out by porting vdb~ from the Max/MSP ejies library. See attached. best, Jamie -- www.postlude.co.uk #N canvas 739 43 512 698 10; #X obj -8 6 inlet~; #X obj 133 10 inlet; #X obj 336 12 inlet; #X obj -7 635 outlet~; #X obj 133 134 max 0.01; #X obj 135 185 /; #X msg 134 159 1000 \$1; #X obj 136 209 phasor~ 13.; #X obj 136 234 cos~; #X obj 136 257 *~ 0.5; #X obj 136 279 +~ 0.5; #X obj 204 37 unpack \$1 \$2; #X obj 204 58 sel 0; #X obj 205 81 f 75; #X obj 203 12 loadbang; #X obj 9 307 sig~; #X obj 9 342 samphold~; #X obj 9 389 vd~ \$0-del; #X obj 9 423 *~; #X obj 9 458 +~; #X obj 170 420 *~; #X obj 170 337 samphold~; #X obj 284 131 s \$0-delaytime; #X obj 10 281 r \$0-delaytime; #X obj 230 308 -~; #X obj 230 277 sig~ 1; #X obj 170 370 vd~ \$0-del; #X obj 74 636 delwrite~ \$0-del 2; #X obj -8 570 +~; #X obj 402 11 inlet; #X obj 403 131 s \$0-feedback; #X obj 49 511 r \$0-feedback; #X obj 10 534 *~ 0.5; #X text -7 666 Pd port of vdb~ for Max/MSP by Benjamin Thigpen & Emmanuel Jourdan; #X text 129 -6 Window size in ms; #X connect 0 0 28 0; #X connect 1 0 4 0; #X connect 2 0 22 0; #X connect 4 0 6 0; #X connect 5 0 7 0; #X connect 6 0 5 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 10 0; #X connect 10 0 16 1; #X connect 10 0 18 1; #X connect 10 0 24 1; #X connect 11 0 12 0; #X connect 11 1 22 0; #X connect 12 0 13 0; #X connect 13 0 4 0; #X connect 14 0 11 0; #X connect 15 0 16 0; #X connect 15 0 21 0; #X connect 16 0 17 0; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 19 0 32 0; #X connect 20 0 19 1; #X connect 21 0 26 0; #X connect 23 0 15 0; #X connect 24 0 21 1; #X connect 24 0 20 1; #X connect 25 0 24 0; #X connect 26 0 20 0; #X connect 28 0 27 0; #X connect 28 0 3 0; #X connect 29 0 30 0; #X connect 31 0 32 1; #X connect 32 0 28 1; #N canvas 211 325 221 297 10; #X obj 39 148 vdb~; #X obj 40 42 adc~; #X obj 39 228 dac~; #X obj 40 67 *~ 0.1; #X floatatom 109 137 5 0 0 0 - - -; #X obj 155 -22 vsl 15 128 0 1 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 12400 1; #X floatatom 155 136 5 0 0 0 - - -; #X text 152 -41 Feedback; #X text 27 -42 Delay time (ms); #X obj 110 -21 vsl 15 128 0 1270 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 0 1; #X connect 0 0 2 0; #X connect 0 0 2 1; #X connect 1 0 3 0; #X connect 3 0 0 0; #X connect 5 0 6 0; #X connect 5 0 0 3; #X connect 9 0 4 0; #X connect 9 0 0 2; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] PdSVN 0.8
Hi Luke, Nice work! On Wed, 2008-06-18 at 05:45 -0700, Luke Iannini wrote: > A modified [getpatchname] is still required; Jamie, do you think you > could take a look at my patch to consider including it (it's in the > zipfile below) so this can Just Work? I'd be happy to check in the > change but I don't want to rustle around in your directories uninvited > :). Yes, no problem. Please go ahead and commit the change. It would be great if you could update the help file also ;-) best, Jamie -- www.postlude.co.uk -- www.postlude.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
