Hi, yes, i am worked with midi controllers for video, i can send the patch at night, maybe you could use for your porpouse.

Best regards

Josè

2011/3/24 Phil Stone pkstone@ucdavis.edu

OK, this was probably too broad a way to pose this. Let me try it this way: I'm not concerned with looping, re-sampling or sample-rate changing. I simply want a low-latency trigger of a sound file from an incoming event. The file(s) may, however, be quite large.

So, is a phasor-scanned [tabread4~] the best way to go about this? Will memory management become an issue if I have 44 or 88 of these large samples in memory at once?

thanks,

Phil

On 3/24/11 11:30 AM, Phil Stone wrote:

...

Hello collective PD mind,

Despite having worked with PD for years, I've never used it as a sample player. I have a project coming up where I will need to build a bank of MIDI-keyboard-triggered samples to play in real-time, with velocity sensitivity and one sample per key. Rather than reinvent the wheel, is there something someone has already done along this line? If not, can anyone give me a basic outline from which I can start?

Phil Stone www.pkstonemusic.com

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hi Phil,

if they'll always play from the beginning and the only control you need is amplitude, then I would try readsf~.

J

On Thu, Mar 24, 2011 at 1:57 PM, Phil Stone pkstone@ucdavis.edu wrote:

OK, this was probably too broad a way to pose this. Let me try it this way: I'm not concerned with looping, re-sampling or sample-rate changing. I simply want a low-latency trigger of a sound file from an incoming event. The file(s) may, however, be quite large.

So, is a phasor-scanned [tabread4~] the best way to go about this? Will memory management become an issue if I have 44 or 88 of these large samples in memory at once?

thanks,

Phil

On 3/24/11 11:30 AM, Phil Stone wrote:

...

Hello collective PD mind,

Despite having worked with PD for years, I've never used it as a sample player. I have a project coming up where I will need to build a bank of MIDI-keyboard-triggered samples to play in real-time, with velocity sensitivity and one sample per key. Rather than reinvent the wheel, is there something someone has already done along this line? If not, can anyone give me a basic outline from which I can start?

Phil Stone www.pkstonemusic.com

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

2011/3/25 Phil Stone pkstone@ucdavis.edu

Hi Jaime,

Thanks for the suggestion, and for further clarifying (in my mind) what I'll need. I think readsf~ won't do because of the "open before play" requirement -- it will introduce latency and prevent re-triggering, if I'm not mistaken.

I guess it's going to be a matter of loading as many tables in memory as I can get away with and using tabread4~ with a phasor.

I think with tabread4~ you have to use the onset in the right inlet for reading longer files. How long are the samples? some other options you may have: some which i tried, without much success though..: linuxsampler/qsampler unfortunately, each time I tried (in the past few years), to trigger samples from pd-alsamidi>qsampler (using qjackctl), the timing is just too unstable/irregular, even when running pd -noaudio. [fluid~] (crashes pd here when I load a soundfont and turn on dsp...) ymmv gr, Tim

Thanks for writing,

Phil

On 3/24/11 11:37 PM, Jaime Oliver wrote:

...

Hi Phil,

if they'll always play from the beginning and the only control you need is amplitude, then I would try readsf~.

J

On Thu, Mar 24, 2011 at 1:57 PM, Phil Stonepkstone@ucdavis.edu wrote:

...

OK, this was probably too broad a way to pose this. Let me try it this way: I'm not concerned with looping, re-sampling or sample-rate changing. I simply want a low-latency trigger of a sound file from an incoming event. The file(s) may, however, be quite large.

So, is a phasor-scanned [tabread4~] the best way to go about this? Will memory management become an issue if I have 44 or 88 of these large samples in memory at once?

thanks,

Phil

On 3/24/11 11:30 AM, Phil Stone wrote:

...

Hello collective PD mind,

Despite having worked with PD for years, I've never used it as a sample player. I have a project coming up where I will need to build a bank of MIDI-keyboard-triggered samples to play in real-time, with velocity sensitivity and one sample per key. Rather than reinvent the wheel, is there something someone has already done along this line? If not, can anyone give me a basic outline from which I can start?

Phil Stone www.pkstonemusic.com

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 03/25/2011 09:44 PM, Xavier Miller wrote:

Wouldn't be possible to mix the best of "both worlds" (tabread4~ and sfread~) by pre-loading the first (milli-)seconds of each sound in memory, then switch to streaming

i remember a couple of years ago something like this was posted to the list. unfortunately i cannot find it in the archive, but basicly the idea was: load a second of audio into a table, start playback of the table and open the rest of the soundfile with readsf, and start readsf-playback with 1 second delay (and switch from tableplayback to diskstream, also with 1 sec. delay). as far as i remember, this worked very well.

bis denn! martin

Hi Phil, the promised... my patch for work with korg padkontrol, easy to use, and very simple.

Best

José

2011/3/25 Charles Goyard cg@fsck.fr

Hi Phil,

Phil Stone wrote:

...

Thanks for the suggestion, and for further clarifying (in my mind) what I'll need. I think readsf~ won't do because of the "open before play" requirement -- it will introduce latency and prevent re-triggering, if I'm not mistaken.

It seems that readsfv~ from moonlib could do the job: it does direct-from-disk reading. I tried with a 650MB wav file with no perceptible latency.

Plus keep in mind that once a file has been read, it can stay for some time in the system disk caches.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

How did I miss this one? Thanks, William, [tabplay~] indeed looks promising.

And thanks for the cool example, Jose.

Phil

On 3/25/11 3:22 PM, William Brent wrote:

Sounds like there's no shortage of options here, but since you don't have to do any transposing, [tabplay~] is useful and just as low latency as a [phasor~] + [tabread4~]. It's great for long files because you don't have to worry about bit precision for the index.

On Fri, Mar 25, 2011 at 6:09 PM, Jose Luis Santorcuato santorcuato76@gmail.com wrote:

...

Hi Phil, the promised... my patch for work with korg padkontrol, easy to use, and very simple. Best José

2011/3/25 Charles Goyardcg@fsck.fr

...

Hi Phil,

Phil Stone wrote:

...

Thanks for the suggestion, and for further clarifying (in my mind) what I'll need. I think readsf~ won't do because of the "open before play" requirement -- it will introduce latency and prevent re-triggering, if I'm not mistaken.

It seems that readsfv~ from moonlib could do the job: it does direct-from-disk reading. I tried with a 650MB wav file with no perceptible latency.

Plus keep in mind that once a file has been read, it can stay for some time in the system disk caches.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-- http://arselectronicachile.blogspot.com http://comunicacionnativa.blogspot.com/ http://www.myspace.com/santorcuato

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

IIRC someone did that using two [tabplay4~] to extend the precision to an effective time of many minutes.

On Fri, 25 Mar 2011 19:04:49 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:

On Fri, 25 Mar 2011, William Brent wrote:

...

Sounds like there's no shortage of options here, but since you don't have to do any transposing, [tabplay~] is useful and just as low latency as a [phasor~] + [tabread4~]. It's great for long files because you don't have to worry about bit precision for the index.

Hmmm, did anyone make a [tabplay4~] abstraction for the purpose of having a variable-speed [tabplay~] that doesn't have a precision problem ? I think that this might be a new idea, but I ask in case it's been done already.

---

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC