Re: [PD] adapting wiimote_navigation_example patch with osculator
With [autoscale] you can now turn off the auto part once it is adjusted. Plus you can save and load settings too. Check the help patch. .hc On Aug 7, 2008, at 3:44 AM, Luigi Rensinghoff wrote: Hi have a look at the "mapping" abstractions they are very useful in this context For the actual point, i usually use "autoscale" to find out what the range should be, but then "expr" (if you know exactly how you have to scale is good for adjusting the range. The x-y coordinates might be the other way around in osculator, check carefully (timeline is a good tool to check the OSC data) Luigi Am 07.08.2008 um 01:41 schrieb punchik punchik: hello im trying to use the wiimote_navigation_example patch but since im on macosx, im trying to use osculator instead of the wiimote object for linux. I can receive my wiimote data in pd with osculator without any problems. But it seems the second outlet of the wiimote object outputs the acceleraion data in a diferent scale than osculator. The acceleration x y z varialbes that i get from osculator goes from 0 to 0.9 and when i use them in the patch instead of the wiimote object everything begins to spin very fast and never stops any idea how to fix this?? thanks p. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list >---< Luigi Rensinghoff [EMAIL PROTECTED] skype:gigischinke ichat:gigicarlo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] netpd server crashes
On Fri, 2008-08-08 at 17:49 -0400, Hans-Christoph Steiner wrote: > Sounds like you guys should try Martin Peach's [tcpserver]. > yeah, that is actually the plan on the mid-term/long run. since basically only [netserver] and [netclient] are really needed from maxlib, i would like to switch to mrpeach's classes. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] interface built with Pd/GEM
hi, I put up a video of a project I did with Pd/GEM http://www.vimeo.com/1493233 Everything is programmed in Pd/GEM, using msd for the movement of the shapes, and pdj for network communication to the other two screens. marius. (only the interface in the left screen is done in pd, the rest was a game engine). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] netpd server crashes
On Aug 8, 2008, at 3:12 PM, Roman Haefeli wrote: > On Fri, 2008-08-08 at 08:25 -0500, John Harrison wrote: >> My interest has been piqued by netpd and a bunch of us here have been >> playing with it. It's pretty fantastic --- there's only one caveat, >> which is that the netpd server crashes and pretty easily at that. >> I've >> seen the netpd.org server crash a bunch of times now. I downloaded >> and >> installed the server patch on an ubuntu Gutsy machine and that >> crashes >> similarly. I looked at the patch --- nothing too complex. I suspect >> there is nothing wrong with the patch itself. >> >> I'm suspecting the problem is with netserver, written by Olaf >> Matthes . >> I suspect this because netsend~ and netreceive~ crash in my use in >> similar ways to what I am seeing now with netpd --- Olaf Matthes >> wrote >> those too. I was wondering if anybody could confirm or refute that >> netserver is what is crashing netpd. It would be great if we fixed >> this. >> In general I think we have a problem with some externals involving >> network communication and if we fixed this in several of the >> externals >> maybe we would solve a bunch of problems at once. I might be up for a >> shot at it myself. > > hi john > > what you describe is known to us, but unfortunately i didn't find a > way > to solve it by myself. also the netpd-server patch running on > netpd.org > crashes from time to time. i am not absolutely sure about the > reason and > i also tried to debug it by running pd within gdb. therefor i compiled > millers pd, zexy and maxlib (the dependencies of the server patch) > with > debug symbols, but unfortunately it still didn't show me the > symbols of > the point where it crashed. i am not too familiar with these tools, so > probably i made something wrong. > from my experience i can at least confirm, that most likely > [netserver] > from maxlib is the trouble maker. from what i can tell, crashes happen > more likely, if several clients disconnect without saying 'adieu'. > (http://en.wikipedia.org/wiki/ > Transmission_Control_Protocol#Connection_termination ) > this happens, when internet connection of a client suddenly is lost or > if pd of a client crashes. sometimes it doesn't crash for months, when > all clients have good connection (an they don't crash too often). > i would be interested to know, what conditions are needed to crash > pd/server-patch on your box. does it behave the same? if so, i > wonder if > [netserver] really complies with tcp. i also wonder what host is > supposed to do if only one end point finishes the connection (and this > what happens, if a client crashes, i suppose). Sounds like you guys should try Martin Peach's [tcpserver]. .hc >> P.S. Some of us tuned in for the netpd jam that we thought happens >> every >> Thursday at 22:00 CEST. Nobody was there except us. Is this just old >> outdated info? >> http://www.netpd.org/Schedule > > yo.. i am very sorry. we are (i should rather say: i am) sometimes > quite > lazy and undisciplined people. actually it is supposed to still be > actual, but during the last weeks there wasn't much traffic and we > often > dropped the sessions (and i was also more busy than usual). but yeah, > lets have jam sessions. probably inform us by mail, if you know > beforehand that you are going to have a session. i would like to join. > there is also this other happening every second tuesday of the month, > where we have our session broadcasted on an internet radio > (http://audioasyl.net). usually we are three or more people there. > > roman > > > > > > ___ > Telefonate ohne weitere Kosten vom PC zum PC: http:// > messenger.yahoo.de > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] netpd server crashes
On Fri, 2008-08-08 at 08:25 -0500, John Harrison wrote: > My interest has been piqued by netpd and a bunch of us here have been > playing with it. It's pretty fantastic --- there's only one caveat, > which is that the netpd server crashes and pretty easily at that. I've > seen the netpd.org server crash a bunch of times now. I downloaded and > installed the server patch on an ubuntu Gutsy machine and that crashes > similarly. I looked at the patch --- nothing too complex. I suspect > there is nothing wrong with the patch itself. > > I'm suspecting the problem is with netserver, written by Olaf Matthes . > I suspect this because netsend~ and netreceive~ crash in my use in > similar ways to what I am seeing now with netpd --- Olaf Matthes wrote > those too. I was wondering if anybody could confirm or refute that > netserver is what is crashing netpd. It would be great if we fixed this. > In general I think we have a problem with some externals involving > network communication and if we fixed this in several of the externals > maybe we would solve a bunch of problems at once. I might be up for a > shot at it myself. hi john what you describe is known to us, but unfortunately i didn't find a way to solve it by myself. also the netpd-server patch running on netpd.org crashes from time to time. i am not absolutely sure about the reason and i also tried to debug it by running pd within gdb. therefor i compiled millers pd, zexy and maxlib (the dependencies of the server patch) with debug symbols, but unfortunately it still didn't show me the symbols of the point where it crashed. i am not too familiar with these tools, so probably i made something wrong. from my experience i can at least confirm, that most likely [netserver] from maxlib is the trouble maker. from what i can tell, crashes happen more likely, if several clients disconnect without saying 'adieu'. (http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination ) this happens, when internet connection of a client suddenly is lost or if pd of a client crashes. sometimes it doesn't crash for months, when all clients have good connection (an they don't crash too often). i would be interested to know, what conditions are needed to crash pd/server-patch on your box. does it behave the same? if so, i wonder if [netserver] really complies with tcp. i also wonder what host is supposed to do if only one end point finishes the connection (and this what happens, if a client crashes, i suppose). > P.S. Some of us tuned in for the netpd jam that we thought happens every > Thursday at 22:00 CEST. Nobody was there except us. Is this just old > outdated info? > http://www.netpd.org/Schedule yo.. i am very sorry. we are (i should rather say: i am) sometimes quite lazy and undisciplined people. actually it is supposed to still be actual, but during the last weeks there wasn't much traffic and we often dropped the sessions (and i was also more busy than usual). but yeah, lets have jam sessions. probably inform us by mail, if you know beforehand that you are going to have a session. i would like to join. there is also this other happening every second tuesday of the month, where we have our session broadcasted on an internet radio (http://audioasyl.net). usually we are three or more people there. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] reset a particle system
hi, is it possible to reset a particle system? delete all existing particles and set all particles to age 0 and position 0. marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] netpd server crashes
My interest has been piqued by netpd and a bunch of us here have been playing with it. It's pretty fantastic --- there's only one caveat, which is that the netpd server crashes and pretty easily at that. I've seen the netpd.org server crash a bunch of times now. I downloaded and installed the server patch on an ubuntu Gutsy machine and that crashes similarly. I looked at the patch --- nothing too complex. I suspect there is nothing wrong with the patch itself. I'm suspecting the problem is with netserver, written by Olaf Matthes . I suspect this because netsend~ and netreceive~ crash in my use in similar ways to what I am seeing now with netpd --- Olaf Matthes wrote those too. I was wondering if anybody could confirm or refute that netserver is what is crashing netpd. It would be great if we fixed this. In general I think we have a problem with some externals involving network communication and if we fixed this in several of the externals maybe we would solve a bunch of problems at once. I might be up for a shot at it myself. -John P.S. Some of us tuned in for the netpd jam that we thought happens every Thursday at 22:00 CEST. Nobody was there except us. Is this just old outdated info? http://www.netpd.org/Schedule ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] problems with pd extended (0.40.3)
martin brinkmann wrote: > Si Mills wrote: > > I've been using [expr~ ] as a workaround >> eg. [expr~ $v1<0.5] > > ok, it is good to know that there is a workaround, actually zexy provides the [>~] objects _additionally_ as abstraction which do exactly this: wrap [expr~] the only problem with this is, that you have to decide beforehand whether you want to have signals or float (messages) on the right-hand input. that's the main reason why zexy also provides [>~] as an external object (that allows both, depending on whether you specify a default argument - just like [+~] and the like) > and i will probably use the expr-method in the future > for compatibility with 'pd vanilla'. but i am not > looking forward to converting all my patches... > thanks for your hint! it's probably always a good idea to try to have a look inside 3rd-party objects; sometimes they really are just abstractions and you can learn a lot... amdsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] physical modelling/general pd
Hello Julian, I have done a wind chime there is 2-3 years ago with PD/GEM/PMPD. I used PHP to get on the web the value of direction and force of wind in differents cities in Europe. Here a link for a video without sound (i remove it from the export) : http://djrayban2.free.fr/Movie/windChime.mov ++ Jack Le 8 août 08 à 12:16, cyrille henry a écrit : > hello, > > > Mark Sexton a écrit : >> Hi Julian >> Building a physical model of a wind chime might be easier than you >> think, if >> you use modal or banded waveguide approaches to physical modelling >> rather >> than the brute force approach of pmpd. > > pmpd aim to model the movement, not the sound. > the hamer and the tube of a simple wind chime could be modeled with > about 10 masses. > To create a physical model of the sound is very different. > but you need both to model the wind chime. > > Cyrille > > > > > > > >> >> If you think of the wind chimes should as stiff bars, banded >> waveguides >> would be ideal and are much more computationally efficient to >> implement than >> brute force approaches: a resonant filter and delay per mode you >> want to >> synthesis. I'd recommend perhaps starting with a simple modal >> implementation using filters and build up from there. This paper >> gives a >> good introduction: >> http://www.cs.ubc.ca/~kvdoel/publications/modalpaper.pdf >> >> >> If you're not familiar with modal synthesis and banded waveguides >> there's >> plenty of information online and Perry Cook's book gives a good >> overview of >> a range of approaches to modelling. >> http://www.cs.princeton.edu/~prc/AKPetersBook.htm >> >> Some starting hints if you want to go down this route: >> >> 1. Create an impulse: a buffer of noise or single sample impulse >> 2. Feed this into perhaps 5 band pass IIR filters with a very >> narrow Q, >> these will provide your resonant modes for each chime. >> 3. The frequencies of these filters will probably be non-integer >> multiples >> of the fundamental, eventually you can get these by analysing an >> actual wind >> chime, but if you wanted to build a proof of concept now then >> these are >> typical modes of an aluminium bar (you can find further modal >> frequency >> ratios in the Csound manual): >> [1, 2.756, 5.423, 8.988, 13.448, 18.680] >> 4. Scale the outputs of each of the resonant filters as >> appropriate, this >> should be straight forward once you've done an audio analysis of >> your wind >> chime. >> >> At this point you have a simple resonating model of a wind chime. >> >> 5. Perhaps replace the impulse: you can remove the resonant >> components of >> your wind chime recording and this will leave you with the >> original noise >> impulse. Using this to trigger your model should help improve >> realism. >> 6. Create a banded waveguide version, by adding feedback delays >> for each >> mode. (have a read of this paper and a look at Fig. 4): >> http://soundlab.cs.princeton.edu/publications/1999_icmc_bar.pdf >> >> There's a few further tweaks and improvements that can be done, but >> something along these lines should give a good result, be fairly >> easy to >> implement and run more efficiently than brute force. >> >> Happy to chat more on or off list on the physical model side or >> algorithmic >> composition side, but you may find it easier than you thought once >> you get >> going. >> >> >> All the best >> >> Mark Sexton >> Senior Lecturer >> MSc Computational Sound >> University of Portsmouth >> >>> Message: 2 >>> Date: Thu, 7 Aug 2008 12:30:51 +0100 >>> From: "Julian Brooks" <[EMAIL PROTECTED]> >>> Subject: [PD] physical modelling/general pd - mentor/tuition sought >>> (money offered) >>> To: >>> Message-ID: <[EMAIL PROTECTED]@virgin.net> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> Hi all, >>> >>> >>> >>> I have a 12 month project as part of a masters degree, where I >>> wish to build >>> a physical model of a wind chime. I then want to use the >>> interface to play >>> some of my indeterminate compositions. I was going to attempt it >>> for my >>> undergraduate degree but realised that it was far too complex for >>> the >>> available time that I had then. >>> >>> >>> >>> I have been using pd for a few years now, list lurking, working >>> through >>> basic examples, building simple tools, using other peoples >>> patches etc. But >>> this is too complex for me to do on my own. At my uni there >>> isn't anyone >>> with better skills than me and I don't know of any local fellow >>> patchers. >>> >>> >>> >>> Now as a musician, when I need to up my skills, I will look to >>> find some >>> lessons when I have got as far as I can on my own. >>> >>> >>> >>> So here goes... >>> >>> >>> >>> Is there anyone with an hour a week to spare who can offer some >>> mentoring/tuition for what we can deem to be the 'going rate'. I >>> am more >>> than happy to do this remotely/online, I'm sure there is a way we >>> can work >>>
Re: [PD] accessing i variable in repeat object?
Le 8 août 08 à 08:00, Frank Barknecht a écrit :
> Hallo,
> punchik punchik hat gesagt: // punchik punchik wrote:
>
>> is it possible to access to the increment variable in repeat?
>> when i repeat a geo in gem having access to the "i " variable
>> allows me creating diferent 3d patterns
>>
>> how can i do something like this with repeat?
>>
>>
>> for (i = 0; i = 10 ; i ++) {
>> if (i%5 ==0 continue;
>> cube
>> translate (i * 2) 0 0;
>> }
>
> You just put a trigger after the repeat and start counting. E.g.
It's also possible to use double gemhead :
Browser/Examples/Gem/02 Advanced/20 double gemhead vs repeat.
++
Jack
>
> [repeat 10]
> |
> [t a b]
> ||
> |[f ]X[+ 1] <= "i"
> ||
> |[mod 5]
> ||
> [translateXYZ]
>
> Ciao
> --
> Frank
>
> ___
> 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] accessing i variable in repeat object?
hello,
you can find example of this kind of stuf in the Gem examples section.
2.Advenced/19.pointer in the pd more_iterating_2
cyrille
punchik punchik a écrit :
> is it possible to access to the increment variable in repeat? when i repeat
> a geo in gem having access to the "i " variable allows me creating diferent
> 3d patterns
>
> how can i do something like this with repeat?
>
>
> for (i = 0; i = 10 ; i ++) {
> if (i%5 ==0 continue;
> cube
> translate (i * 2) 0 0;
> }
>
>
> thanls
>
>
>
>
>
>
>
> ___
> 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] physical modelling/general pd
hello, Mark Sexton a écrit : > Hi Julian > Building a physical model of a wind chime might be easier than you think, if > you use modal or banded waveguide approaches to physical modelling rather > than the brute force approach of pmpd. pmpd aim to model the movement, not the sound. the hamer and the tube of a simple wind chime could be modeled with about 10 masses. To create a physical model of the sound is very different. but you need both to model the wind chime. Cyrille > > If you think of the wind chimes should as stiff bars, banded waveguides > would be ideal and are much more computationally efficient to implement than > brute force approaches: a resonant filter and delay per mode you want to > synthesis. I'd recommend perhaps starting with a simple modal > implementation using filters and build up from there. This paper gives a > good introduction: > http://www.cs.ubc.ca/~kvdoel/publications/modalpaper.pdf > > > If you're not familiar with modal synthesis and banded waveguides there's > plenty of information online and Perry Cook's book gives a good overview of > a range of approaches to modelling. > http://www.cs.princeton.edu/~prc/AKPetersBook.htm > > Some starting hints if you want to go down this route: > > 1. Create an impulse: a buffer of noise or single sample impulse > 2. Feed this into perhaps 5 band pass IIR filters with a very narrow Q, > these will provide your resonant modes for each chime. > 3. The frequencies of these filters will probably be non-integer multiples > of the fundamental, eventually you can get these by analysing an actual wind > chime, but if you wanted to build a proof of concept now then these are > typical modes of an aluminium bar (you can find further modal frequency > ratios in the Csound manual): > [1, 2.756, 5.423, 8.988, 13.448, 18.680] > 4. Scale the outputs of each of the resonant filters as appropriate, this > should be straight forward once you've done an audio analysis of your wind > chime. > > At this point you have a simple resonating model of a wind chime. > > 5. Perhaps replace the impulse: you can remove the resonant components of > your wind chime recording and this will leave you with the original noise > impulse. Using this to trigger your model should help improve realism. > 6. Create a banded waveguide version, by adding feedback delays for each > mode. (have a read of this paper and a look at Fig. 4): > http://soundlab.cs.princeton.edu/publications/1999_icmc_bar.pdf > > There's a few further tweaks and improvements that can be done, but > something along these lines should give a good result, be fairly easy to > implement and run more efficiently than brute force. > > Happy to chat more on or off list on the physical model side or algorithmic > composition side, but you may find it easier than you thought once you get > going. > > > All the best > > Mark Sexton > Senior Lecturer > MSc Computational Sound > University of Portsmouth > >> Message: 2 >> Date: Thu, 7 Aug 2008 12:30:51 +0100 >> From: "Julian Brooks" <[EMAIL PROTECTED]> >> Subject: [PD] physical modelling/general pd - mentor/tuition sought >> (money offered) >> To: >> Message-ID: <[EMAIL PROTECTED]@virgin.net> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> >> >> >> I have a 12 month project as part of a masters degree, where I wish to build >> a physical model of a wind chime. I then want to use the interface to play >> some of my indeterminate compositions. I was going to attempt it for my >> undergraduate degree but realised that it was far too complex for the >> available time that I had then. >> >> >> >> I have been using pd for a few years now, list lurking, working through >> basic examples, building simple tools, using other peoples patches etc. But >> this is too complex for me to do on my own. At my uni there isn't anyone >> with better skills than me and I don't know of any local fellow patchers. >> >> >> >> Now as a musician, when I need to up my skills, I will look to find some >> lessons when I have got as far as I can on my own. >> >> >> >> So here goes... >> >> >> >> Is there anyone with an hour a week to spare who can offer some >> mentoring/tuition for what we can deem to be the 'going rate'. I am more >> than happy to do this remotely/online, I'm sure there is a way we can work >> it out. There would be full credit given of course. >> >> >> >> Pmpd seems like the way to go with this. I have worked through the >> examples, and, although I have my eye on what examples I would presume to be >> the best starting points, I'm struggling to get started. The physical >> modelling is where I first need to start but there's loads of pd stuff I >> would like to be able to work through with someone, so this could be a (me >> love you)longtime regular small money earner, if anyone's interested. >> >> >> >> I am in Hebden Bridge, West Yorkshire, UK, by the way. Any pd'ers local, >> give us a shout. >> >> >> >>
Re: [PD] Recording MIDI data with PD as synch master
Ignacio Viano wrote: > Hello. I'm sending an enormous quantity of note messages through a virtual > MIDI port out to some virtual orchestras. All messages are synchronized with > a PD metronome that may vary. I want all this into an "as "good" as possible > written score". Even this idea may not work at all. Of course, I could do it > all manually by recording the raw MIDI messages, printing and transcribing > them into score, but it should be easier. Any ideas? I tried using mrpeach's [midifile] (which you send metro ticks to control the recording) together with Lilypond's midi2ly tool, had mixed results: due to my inexperience I couldn't figure out how to get midi2ly to understand triplet rhythms - I'm sure it's possible - but the other problem I had was relating to chords, I only had success with monophonic voices each on their own MIDI channel. It would probably have been quicker to transcribe it by hand for my (short and simple) piece, but not as fun a learning experience. Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] accessing i variable in repeat object?
Frank Barknecht wrote:
> Hallo,
> punchik punchik hat gesagt: // punchik punchik wrote:
>
>> is it possible to access to the increment variable in repeat? when i
>> repeat a geo in gem having access to the "i " variable allows me creating
>> diferent 3d patterns
>>
>> how can i do something like this with repeat?
>>
>>
>> for (i = 0; i = 10 ; i ++) {
use [f]X[+ 1] like frank said below, but see my comments there..
>> if (i%5 ==0 continue;
use [spigot] for this part
>> cube
>> translate (i * 2) 0 0;
>> }
>
> You just put a trigger after the repeat and start counting. E.g.
>
I'd put a [t a b] here...
> [repeat 10]
> |
> [t a b]
> ||
...connected to "0" that resets the [f]
> |[f ]X[+ 1] <= "i"
then for the continue stuff it would be
|[t f f]
> ||
> |[mod 5]
> ||
|[!= 0]
||
[spigot]
| (from [t f f])
| |
> [translateXYZ]
>
> Ciao
Hope this makes sense,
Claude
--
http://claudiusmaximus.goto10.org
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] a full-featured sampleplayer
On Thu, 2008-08-07 at 17:39 +0200, Atte André Jensen wrote: > Hi > > I've build a sample player abstraction, and now I just thought of one > more feature it needs, and that makes me think I need to redo it again. I usually look to pdmtl abstractions for this kind of thing. If nothing more they can serve as a starting point or a source of ideas. I think their sample.groove~ might do what you need? http://wiki.puredata.info/en/sample.groove~ Jamie -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] physical modelling/general pd
Hi Julian Building a physical model of a wind chime might be easier than you think, if you use modal or banded waveguide approaches to physical modelling rather than the brute force approach of pmpd. If you think of the wind chimes should as stiff bars, banded waveguides would be ideal and are much more computationally efficient to implement than brute force approaches: a resonant filter and delay per mode you want to synthesis. I'd recommend perhaps starting with a simple modal implementation using filters and build up from there. This paper gives a good introduction: http://www.cs.ubc.ca/~kvdoel/publications/modalpaper.pdf If you're not familiar with modal synthesis and banded waveguides there's plenty of information online and Perry Cook's book gives a good overview of a range of approaches to modelling. http://www.cs.princeton.edu/~prc/AKPetersBook.htm Some starting hints if you want to go down this route: 1. Create an impulse: a buffer of noise or single sample impulse 2. Feed this into perhaps 5 band pass IIR filters with a very narrow Q, these will provide your resonant modes for each chime. 3. The frequencies of these filters will probably be non-integer multiples of the fundamental, eventually you can get these by analysing an actual wind chime, but if you wanted to build a proof of concept now then these are typical modes of an aluminium bar (you can find further modal frequency ratios in the Csound manual): [1, 2.756, 5.423, 8.988, 13.448, 18.680] 4. Scale the outputs of each of the resonant filters as appropriate, this should be straight forward once you've done an audio analysis of your wind chime. At this point you have a simple resonating model of a wind chime. 5. Perhaps replace the impulse: you can remove the resonant components of your wind chime recording and this will leave you with the original noise impulse. Using this to trigger your model should help improve realism. 6. Create a banded waveguide version, by adding feedback delays for each mode. (have a read of this paper and a look at Fig. 4): http://soundlab.cs.princeton.edu/publications/1999_icmc_bar.pdf There's a few further tweaks and improvements that can be done, but something along these lines should give a good result, be fairly easy to implement and run more efficiently than brute force. Happy to chat more on or off list on the physical model side or algorithmic composition side, but you may find it easier than you thought once you get going. All the best Mark Sexton Senior Lecturer MSc Computational Sound University of Portsmouth > > Message: 2 > Date: Thu, 7 Aug 2008 12:30:51 +0100 > From: "Julian Brooks" <[EMAIL PROTECTED]> > Subject: [PD] physical modelling/general pd - mentor/tuition sought > (money offered) > To: > Message-ID: <[EMAIL PROTECTED]@virgin.net> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > > I have a 12 month project as part of a masters degree, where I wish to build > a physical model of a wind chime. I then want to use the interface to play > some of my indeterminate compositions. I was going to attempt it for my > undergraduate degree but realised that it was far too complex for the > available time that I had then. > > > > I have been using pd for a few years now, list lurking, working through > basic examples, building simple tools, using other peoples patches etc. But > this is too complex for me to do on my own. At my uni there isn't anyone > with better skills than me and I don't know of any local fellow patchers. > > > > Now as a musician, when I need to up my skills, I will look to find some > lessons when I have got as far as I can on my own. > > > > So here goes... > > > > Is there anyone with an hour a week to spare who can offer some > mentoring/tuition for what we can deem to be the 'going rate'. I am more > than happy to do this remotely/online, I'm sure there is a way we can work > it out. There would be full credit given of course. > > > > Pmpd seems like the way to go with this. I have worked through the > examples, and, although I have my eye on what examples I would presume to be > the best starting points, I'm struggling to get started. The physical > modelling is where I first need to start but there's loads of pd stuff I > would like to be able to work through with someone, so this could be a (me > love you)longtime regular small money earner, if anyone's interested. > > > > I am in Hebden Bridge, West Yorkshire, UK, by the way. Any pd'ers local, > give us a shout. > > > > Best wishes to all, > > > > Jb > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Primordial Style Guide
Hi All Okay, I've now organized the discussion so far into the "Primordial Style Guide": http://puredata.info/docs/style-guide/PrimordialStyleGuide which establishes the beginnings of a structure and gives us some nice topics to fill out. Next, I'll start to whittle this down, and, if necessary, start threads for particular topics so the zeitgeist can be distilled. But, while I do that, feel free to comment on the now available "big picture" as it stands. Best Luke ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] problems with pd extended (0.40.3)
Si Mills wrote: > I've been using [expr~ ] as a workaround > > eg. [expr~ $v1<0.5] ok, it is good to know that there is a workaround, and i will probably use the expr-method in the future for compatibility with 'pd vanilla'. but i am not looking forward to converting all my patches... thanks for your hint! bis denn! martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] a full-featured sampleplayer
On Thu, 2008-08-07 at 23:41 +0200, Atte André Jensen wrote: > Roman Haefeli wrote: > > Thanks for your input! > > > i think there is tons of such abstractions around. anyway, i like to > > re-implement it again and again everytime i need it, because there is > > always little things that i would like to have different from the > > current implementation and also it is always a good exercise (and > > probably i do better this time than last time). > > Hmm, I get your point. I had hope to do the sample_player to end all > sample_players (and then make some music with it) :-) yo, i get your point as well ;-) > > i wouldn't make your abstraction [phasor~] based, because of the problem > > you already sketched out: if you change the rate during the playback, > > you don't know when it is finished. that is why i propose to make any > > table based sampleplayer based on [vline~]. since you need to calculate > > the start-, endpoint and duration, you know at any time, where the index > > currently is (by calculating the current position from [timer] output > > and the three values i mentioned above). this way you can change the > > rate at any time you want, > > I don't understand. Below you state "that you cannot continuously change > the playback speed", what's the difference? sorry, i think i was not clear: if you go for the [vline~] route, then you can change the speed at any time, but only at message rate (you have to send it a new message for the new speed). theoretically you can send it as many messages as you want, but this is probably not too effficient. on the other hand, you can send a continuous audio signal to the left inlet of a [phasor~], which means, that you can continuously change (no steps) the speed of the sampleplayer. personally, i never had a case where i needed to _continuously_ change the speed and i would lack the math to calculate the current position anyway, so i always went for [vline~] route. > > you just need to recalculate start, end and > > duration for [vline~]. it looks more complicated at the beginning, but > > it is the cleanest solution i can think of. > > > > there is one disadvantage of the [vline~]-approach compared to the > > [phasor~]: you cannot continuously change the playback speed. so it is > > yours to decide, which way to go. > > I just know, one day, I'm gonna want to touch that pitch bender of > modulate that playback rate... yo, this is what i meant with continuously changing the speed. hm. actually i don't know how to do that, if something like crossfading is needed. interesting task. roman ___ Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
