Hi,
Does anyone have any experience doing synthesis of Flute sounds in PD? I am looking for a physical modelling style synthesis like that promised by [flute~] from Percolate. Sadly this external doesn't work on my machine. I am about to try to get STK support via flext, and will report back if successful.
Any other advice on this matter would be appreciated.
Jamie
maybe the oboe from andy's 'christchurch' track would be a good start:
On Fri, 2007-04-27 at 18:40 +0900, hard off wrote:
maybe the oboe from andy's 'christchurch' track would be a good start:
Thanks, that looks pretty good, I'm always stealing stuff from Andy's site, it's such a great resource.
It turns out that I solved the problem by adding a Linux Makefile to Geunther Geiger's experimental stk object in CVS. Suddenly the world of STK possibilities has opened up...
best,
Jamie
Hello,
Patricio De La Cuadra has done some flext objects for physical modelling of flute like instrument. I'm not sure if I can give his sources, maybe you can directly contact him:
pdelac@ccrma.stanford.edu
Btw, this will be a part of my PhD work, so in a few month we'll have some Boehm flute models in pd :)
Greetings
Nicolas
Jamie Bullock a écrit :
Hi,
Does anyone have any experience doing synthesis of Flute sounds in PD? I am looking for a physical modelling style synthesis like that promised by [flute~] from Percolate. Sadly this external doesn't work on my machine. I am about to try to get STK support via flext, and will report back if successful.
Any other advice on this matter would be appreciated.
Jamie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That will be nice. For music I think a few more medium level objects like in Perrys toolkit, things like an efficient general purpose pipe model and bowed string model. We really should aim to have a kind of decent Pd orchestra. A lot of work for any one person, but together it could be done one instrument at a time.
On Fri, 27 Apr 2007 14:05:25 +0200 Nicolas Montgermont nicolas_montgermont@yahoo.fr wrote:
Hello,
Patricio De La Cuadra has done some flext objects for physical modelling of flute like instrument. I'm not sure if I can give his sources, maybe you can directly contact him:
pdelac@ccrma.stanford.edu
Btw, this will be a part of my PhD work, so in a few month we'll have some Boehm flute models in pd :)
Greetings
Nicolas
Jamie Bullock a écrit :
Hi,
Does anyone have any experience doing synthesis of Flute sounds in PD? I am looking for a physical modelling style synthesis like that promised by [flute~] from Percolate. Sadly this external doesn't work on my machine. I am about to try to get STK support via flext, and will report back if successful.
Any other advice on this matter would be appreciated.
Jamie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Nicolas Montgermont http://nicomon.basseslumieres.org
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't know well the toolkit in question, but I think in a way to create a kind of orchestra, there should be at least two organised categories:
controls but sounds sometimes weird and are heavy to compute.
and control. or perhaps two categories only defined by the complexity of the synthesis. This way the user can choose regarding his needs and doesn't need to dig each time he wants to use an instrument.
+n
Andy Farnell a écrit :
That will be nice. For music I think a few more medium level objects like in Perrys toolkit, things like an efficient general purpose pipe model and bowed string model. We really should aim to have a kind of decent Pd orchestra. A lot of work for any one person, but together it could be done one instrument at a time.
That's good. A solo or featured instrument might use an expensive physical model, but cheaper methods for the backing instruments. Maybe some kind of namespace could be started now [orc-flute], [orc-cello] and so on. A coherent performance interface would be a great start, something simple akin to MIDI {/ducks}
Actually the structure isn't as important as the flexibility and documentation. One should be able to query an instrument with a [help( message and get a print out like
/string/position/ /string/unitweight/ /bow/pressure/
all with normalised scales in OSC style so you know what is addressable
Keep the same general interface and every time someone makes a nice instrument they can put it in the next available namespace slot like [orc-trombone-22], [orc-trombone-23]...
Andy
On Fri, 27 Apr 2007 17:44:50 +0200 Nicolas Montgermont nicolas_montgermont@yahoo.fr wrote:
I don't know well the toolkit in question, but I think in a way to create a kind of orchestra, there should be at least two organised categories:
- one devoted to physically modeled instrument, that allows complex
controls but sounds sometimes weird and are heavy to compute.
- one oriented towards signal models that should be easier to compute
and control. or perhaps two categories only defined by the complexity of the synthesis. This way the user can choose regarding his needs and doesn't need to dig each time he wants to use an instrument.
+n
Andy Farnell a écrit :
That will be nice. For music I think a few more medium level objects like in Perrys toolkit, things like an efficient general purpose pipe model and bowed string model. We really should aim to have a kind of decent Pd orchestra. A lot of work for any one person, but together it could be done one instrument at a time.
-- Nicolas Montgermont http://nicomon.basseslumieres.org
Great-great!
Andy Farnell a écrit :
That's good. A solo or featured instrument might use an expensive physical model, but cheaper methods for the backing instruments. Maybe some kind of namespace could be started now [orc-flute], [orc-cello] and so on. A coherent performance interface would be a great start, something simple akin to MIDI {/ducks}
I agree with the namespace, simple and clear. I also think that midi notes combined with a few continuous parameters should be sufficient.
Actually the structure isn't as important as the flexibility and documentation. One should be able to query an instrument with a [help( message and get a print out like
/string/position/ /string/unitweight/ /bow/pressure/
all with normalised scales in OSC style so you know what is addressable
Definitely.
Keep the same general interface and every time someone makes a nice instrument they can put it in the next available namespace slot like [orc-trombone-22], [orc-trombone-23]...
In order to handle the desired quality, I see two possibilities:
model.
In both case, the simpler model should be the default one, and when somenone wants something more precise, he asks for it.
I can handle the [orc-flute-1] object. A month or two for the simple release...
+n
Hallo, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
Andy Farnell a écrit :
That's good. A solo or featured instrument might use an expensive physical model, but cheaper methods for the backing instruments. Maybe some kind of namespace could be started now [orc-flute], [orc-cello] and so on. A coherent performance interface would be a great start, something simple akin to MIDI {/ducks}
I agree with the namespace, simple and clear. I also think that midi notes combined with a few continuous parameters should be sufficient.
I thought so, too, however instead of midi notes I'm not in favour of midi notes anymore and would strongly vote for frequency inputs for all instruments. It's more flexible in the long run, and in the short run will make alternate tunings easier.
Actually the structure isn't as important as the flexibility and documentation. One should be able to query an instrument with a [help( message and get a print out like
/string/position/ /string/unitweight/ /bow/pressure/
all with normalised scales in OSC style so you know what is addressable
Definitely.
Note that you'll probably want to have instance-specific OSC targets like "/guitar1/string/position". At least I found these immensly useful in Memento/RRADical. You can still set all instances with a wildcard like "/*/string/position".
While we're at Memento: It automatically creates OSC-targets for everything. Getting feedback about available targets is on the TODO list. What will probably be done this weekend is a massive reduction in the number of externals needed by Memento. My realistic goal is to get down to just [pool] and [OSCroute], and later [pool] will be factored out as well and become optional. Then a bit later on Memento will marry SSSAD and they will have a child.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, Apr 27, 2007 at 07:34:25PM +0200, Frank Barknecht wrote:
While we're at Memento: It automatically creates OSC-targets for everything. Getting feedback about available targets is on the TODO list. What will probably be done this weekend is a massive reduction in the number of externals needed by Memento. My realistic goal is to get down to just [pool] and [OSCroute], and later [pool] will be factored out as well and become optional. Then a bit later on Memento will marry SSSAD and they will have a child.
Awesome, awesome, awesome I can't wait, Frank!
It would be really nice if the OSC externals could make it into Miller's canonical Pd too. I don't see why MIDI is in there by OSC isn't. Maybe someone just needs to make a full suite of Miller-style help files and submit the package to him.
That would mean that there would be an industrial strength state-saving mechanism for Pd that people could just "drop in" and use with their OSC enabled programs and devices. I'm excited!
Chris.
On Fri, 27 Apr 2007 19:34:25 +0200 Frank Barknecht fbar@footils.org wrote:
Hallo, Nicolas Montgermont hat gesagt: // Nicolas Montgermont wrote:
Andy Farnell a écrit :
That's good. A solo or featured instrument might use an expensive physical model, but cheaper methods for the backing instruments. Maybe some kind of namespace could be started now [orc-flute], [orc-cello] and so on. A coherent performance interface would be a great start, something simple akin to MIDI {/ducks}
I agree with the namespace, simple and clear. I also think that midi notes combined with a few continuous parameters should be sufficient.
I thought so, too, however instead of midi notes I'm not in favour of midi notes anymore and would strongly vote for frequency inputs for all instruments. It's more flexible in the long run, and in the short run will make alternate tunings easier.
Okay, good point, let's have pd orc instruments be frequency(Hz) driven and leave the user to add [mtof] as needed.
Actually the structure isn't as important as the flexibility and documentation. One should be able to query an instrument with a [help( message and get a print out like
/string/position/ /string/unitweight/ /bow/pressure/
all with normalised scales in OSC style so you know what is addressable
Definitely.
Note that you'll probably want to have instance-specific OSC targets like "/guitar1/string/position". At least I found these immensly useful in Memento/RRADical. You can still set all instances with a wildcard like "/*/string/position".
While we're at Memento: It automatically creates OSC-targets for everything. Getting feedback about available targets is on the TODO list. What will probably be done this weekend is a massive reduction in the number of externals needed by Memento. My realistic goal is to get down to just [pool] and [OSCroute], and later [pool] will be factored out as well and become optional. Then a bit later on Memento will marry SSSAD and they will have a child.
A great improvement Frank. Imho both are are a bit unweildy at present because of deps. A much simplified parameter routing and storage layer would help a lot.
I wonder, can such a thing be generalised enough to form a wrapper that almost any instrument DSP core can be plugged into.
Flute is a great one to start with Nicolas, it's parameters are pretty much fixed and it's monophonic. When that's in place we have a template and I will wrap a few of my signal synthesis instruments in the same style.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, Apr 28, 2007 at 02:12:50PM +0100, Andy Farnell wrote:
On Fri, 27 Apr 2007 19:34:25 +0200 Frank Barknecht fbar@footils.org wrote:
factored out as well and become optional. Then a bit later on Memento will marry SSSAD and they will have a child.
A great improvement Frank. Imho both are are a bit unweildy at present because of deps.
I don't know what you mean; SSSAD has no dependencies outside of Pd itself. It's main problem is that it isn't as feature rich as memento.
Chris.
Both for different reasons Chris, [pool] is an external I've had problems compiling and getting to work consistently, and SSSAD is overly complex imho.
I think its great if a simple to use, intuitive, consistent and completely intrinsic solution can be arrived at.
On Sat, 28 Apr 2007 12:27:47 +0800 Chris McCormick chris@mccormick.cx wrote:
On Sat, Apr 28, 2007 at 02:12:50PM +0100, Andy Farnell wrote:
On Fri, 27 Apr 2007 19:34:25 +0200 Frank Barknecht fbar@footils.org wrote:
factored out as well and become optional. Then a bit later on Memento will marry SSSAD and they will have a child.
A great improvement Frank. Imho both are are a bit unweildy at present because of deps.
I don't know what you mean; SSSAD has no dependencies outside of Pd itself. It's main problem is that it isn't as feature rich as memento.
Chris.
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Both for different reasons Chris, [pool] is an external I've had problems compiling and getting to work consistently, and SSSAD is overly complex imho.
Hm, really, but what is complex about having to just cross-connect a slider like this:
[hsl]X[sssad name]
and have it state-saved?
Frank Barknecht _ ______footils.org_ __goto10.org__
I just never got it to work and I don't know why. It's quite a long time since I tried it though so if you send me the abstraction and I'll try again.
On Sat, 28 Apr 2007 08:27:22 +0200 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Both for different reasons Chris, [pool] is an external I've had problems compiling and getting to work consistently, and SSSAD is overly complex imho.
Hm, really, but what is complex about having to just cross-connect a slider like this:
[hsl]X[sssad name]
and have it state-saved?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Okay, I found the last sssad I tried, and it's got a missing part called _sssad/singleton
On Sat, 28 Apr 2007 08:27:22 +0200 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Both for different reasons Chris, [pool] is an external I've had problems compiling and getting to work consistently, and SSSAD is overly complex imho.
Hm, really, but what is complex about having to just cross-connect a slider like this:
[hsl]X[sssad name]
and have it state-saved?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Okay, I found the last sssad I tried, and it's got a missing part called _sssad/singleton
It's included in the CVS here: http://pure-data.cvs.sourceforge.net/pure-data/abstractions/footils/sssad/
Do you remember where you downloaded the sssad without singleton.pd?
Frank Barknecht _ ______footils.org_ __goto10.org__
Cheers Frank, got singleton, but also needed to get [list_argument], and [ssad-persistance]. I'm not sure why I had an incomplete copy before, but anyway that's why I say "complicated". Not complicated to use in theory.
On Sat, 28 Apr 2007 13:43:10 +0200 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Okay, I found the last sssad I tried, and it's got a missing part called _sssad/singleton
It's included in the CVS here: http://pure-data.cvs.sourceforge.net/pure-data/abstractions/footils/sssad/
Do you remember where you downloaded the sssad without singleton.pd?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
IIRC, SSAD has a major dependancy with Frank's list-abs. If you have those, it should work, right Frank?
~Kyle
On 4/28/07, Andy Farnell padawan12@obiwannabe.co.uk wrote:
Cheers Frank, got singleton, but also needed to get [list_argument], and [ssad-persistance]. I'm not sure why I had an incomplete copy before, but anyway that's why I say "complicated". Not complicated to use in theory.
On Sat, 28 Apr 2007 13:43:10 +0200 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Okay, I found the last sssad I tried, and it's got a missing part called _sssad/singleton
It's included in the CVS here: http://pure-data.cvs.sourceforge.net/pure-data/abstractions/footils/sssad/
Do you remember where you downloaded the sssad without singleton.pd?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
IIRC, SSAD has a major dependancy with Frank's list-abs. If you have those, it should work, right Frank?
No, SSSAD is completely standalone and doesn't require anything but pd-0.39 or up. One of the "S" in its name stands for "simplistic" so simplicity was one of my goals.
Frank Barknecht _ ______footils.org_ __goto10.org__