I like using delay lines because it seems like an elegant solution to the problem, but maybe it's just complicating things.
As for the click, you might be able to use a sample and hold object and adjust the way the sample is written into the delay line. Come to think of it, maybe the array version would be better because you could samphold at every loop start. but wouldn't it be more efficient to write the delay line correctly the first time?
here's something to start with.
===== Original Message From Ian Smith-Heisters heisters@0x09.com ===== Hi list,
I'm trying to build a gizmo that will take adc~, throw it into a buffer of some sort and loop it. Then you could create another and they would be layered over eachother. I think this is a thing that performance musicians often buy as hardware.
The way I initially went about it is using a delay loop. You hit a button, and it routes sound from adc~ into a delwrite~, then after a defined amount of time it switches the input from the delwrite~ over to a delread~ so that the delay starts looping.
I was just wondering if it would be better to implement this using arrays--which has more overhead? Are there other factors?
And while I'm at it, is there any neato trick to getting rid of the click at the seam of the loop besides turning the amplitude down with a line?
Thanks, Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Where did this original mail come from?? I don't have it in my in-box........<confused>
Well there are many tools to do this. Writing your own, I would use the xsample external collection from Thomas Grill: http://grrrr.org/ext/xsample/ (this can take care of those clicks at the start/end of loops).
Then there's Eric Skogens looping framework thing GYRE: http://www.audionerd.com/projects/pd/gyre/
And lastly there's my very own loopsampler: http://www.loopit.org/ (bear in mind the flash version uses MIDI for triggering and requires a number of hard-to-find externals - write me if you have problems).
Regards,
Matt
-=-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org/ -=-=-=-=-=-=-=-=-=-=-=-=- ----- Original Message ----- From: "ba" ba@uvic.ca To: "Ian Smith-Heisters" heisters@0x09.com; "pd-list" pd-list@iem.at Sent: Thursday, October 07, 2004 3:38 AM Subject: RE: [PD] Layered loops: Delays or Arrays?
I like using delay lines because it seems like an elegant solution to the problem, but maybe it's just complicating things.
As for the click, you might be able to use a sample and hold object and
adjust
the way the sample is written into the delay line. Come to think of it,
maybe
the array version would be better because you could samphold at every loop start. but wouldn't it be more efficient to write the delay line
correctly
the first time?
here's something to start with.
===== Original Message From Ian Smith-Heisters heisters@0x09.com ===== Hi list,
I'm trying to build a gizmo that will take adc~, throw it into a buffer of some sort and loop it. Then you could create another and they would be layered over eachother. I think this is a thing that performance musicians often buy as hardware.
The way I initially went about it is using a delay loop. You hit a button, and it routes sound from adc~ into a delwrite~, then after a defined amount of time it switches the input from the delwrite~ over to a delread~ so that the delay starts looping.
I was just wondering if it would be better to implement this using arrays--which has more overhead? Are there other factors?
And while I'm at it, is there any neato trick to getting rid of the click at the seam of the loop besides turning the amplitude down with a line?
Thanks, Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Thanks for the links. I'm trying to avoid using any non-standard libraries (like Thomas') so that it's as portable as possible. Also, I tend to build stuff from scratch so that I can understand them.
Loopit.org says you're performing in Southampton. Southampton MA? That Jamma patch is a hell of a nice piece of work.
Cheers, Ian
matthew jones wrote:
Where did this original mail come from?? I don't have it in my in-box........<confused>
Well there are many tools to do this. Writing your own, I would use the xsample external collection from Thomas Grill: http://grrrr.org/ext/xsample/ (this can take care of those clicks at the start/end of loops).
Then there's Eric Skogens looping framework thing GYRE: http://www.audionerd.com/projects/pd/gyre/
And lastly there's my very own loopsampler: http://www.loopit.org/ (bear in mind the flash version uses MIDI for triggering and requires a number of hard-to-find externals - write me if you have problems).
Regards,
Matt
-=-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org/ -=-=-=-=-=-=-=-=-=-=-=-=- ----- Original Message ----- From: "ba" ba@uvic.ca To: "Ian Smith-Heisters" heisters@0x09.com; "pd-list" pd-list@iem.at Sent: Thursday, October 07, 2004 3:38 AM Subject: RE: [PD] Layered loops: Delays or Arrays?
I like using delay lines because it seems like an elegant solution to the problem, but maybe it's just complicating things.
As for the click, you might be able to use a sample and hold object and
adjust
the way the sample is written into the delay line. Come to think of it,
maybe
the array version would be better because you could samphold at every loop start. but wouldn't it be more efficient to write the delay line
correctly
the first time?
here's something to start with.
===== Original Message From Ian Smith-Heisters heisters@0x09.com ===== Hi list,
I'm trying to build a gizmo that will take adc~, throw it into a buffer of some sort and loop it. Then you could create another and they would be layered over eachother. I think this is a thing that performance musicians often buy as hardware.
The way I initially went about it is using a delay loop. You hit a button, and it routes sound from adc~ into a delwrite~, then after a defined amount of time it switches the input from the delwrite~ over to a delread~ so that the delay starts looping.
I was just wondering if it would be better to implement this using arrays--which has more overhead? Are there other factors?
And while I'm at it, is there any neato trick to getting rid of the click at the seam of the loop besides turning the amplitude down with a line?
Thanks, Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi
anyone knows of a firewire sound card that runs ok under osx and linux?. I want it to run PD on a powerbook 12". USB2.0 sound cards also could be a solution but i preffer firewire. thanks and sorry for asking OT questions
Hallo, altern hat gesagt: // altern wrote:
anyone knows of a firewire sound card that runs ok under osx and linux?.
AFAIK no firewire soundcard runs on Linux yet, but developers are getting close.
Frank Barknecht _ ______footils.org__
I liked delay lines because they seem elegant too. However, when I got 4 of them going I started getting stack overflows. I went over to arrays, which seem more easily manipulatable, maybe just because I'm more familiar with them. More importantly, they haven't caused stack overflows ;)
Here's what I came up with. I'll probably add some more features, but it's functional. It's for a friend who was about to put down god knows how much money on the hardware version, and I said that her laptop could probably do the same job a lot better. Getting the envelope was the toughest part. I tried a few different schemes and think using a threshold~ and a line~ works best.
Thanks for the patch, it's very interesting, though I did have some problems figuring it out.
-Ian
ba wrote:
I like using delay lines because it seems like an elegant solution to the problem, but maybe it's just complicating things.
As for the click, you might be able to use a sample and hold object and adjust the way the sample is written into the delay line. Come to think of it, maybe the array version would be better because you could samphold at every loop start. but wouldn't it be more efficient to write the delay line correctly the first time?
here's something to start with.
===== Original Message From Ian Smith-Heisters heisters@0x09.com ===== Hi list,
I'm trying to build a gizmo that will take adc~, throw it into a buffer of some sort and loop it. Then you could create another and they would be layered over eachother. I think this is a thing that performance musicians often buy as hardware.
The way I initially went about it is using a delay loop. You hit a button, and it routes sound from adc~ into a delwrite~, then after a defined amount of time it switches the input from the delwrite~ over to a delread~ so that the delay starts looping.
I was just wondering if it would be better to implement this using arrays--which has more overhead? Are there other factors?
And while I'm at it, is there any neato trick to getting rid of the click at the seam of the loop besides turning the amplitude down with a line?
Thanks, Ian
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
#N canvas 20 350 741 278 10; #X obj 248 256 dac~; #X msg 9 42 ; pd dsp $1; #X obj 9 11 tgl 25 0 empty empty DSP 5 12 0 10 -143491 -258699 -262144 0 1; #X obj 164 13 adc~; #X obj 104 69 mux~; #X obj 81 11 hradio 15 1 0 2 empty empty stream_select 0 -6 0 8 -99865 -262144 -66577 1; #X obj 206 37 osc~; #X obj 206 15 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10 -262144 -1 -1 2122 256; #X obj 6 124 sample_catcher 441000; #X obj 190 124 sample_catcher 441000; #X obj 372 124 sample_catcher 441000; #X obj 554 124 sample_catcher 441000; #X obj 556 92 bng 20 250 50 0 empty empty Synchronize 0 -6 0 10 -195568 -99865 -1; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 3 1 4 0; #X connect 4 0 8 0; #X connect 4 0 9 0; #X connect 4 0 10 0; #X connect 4 0 11 0; #X connect 5 0 4 0; #X connect 6 0 4 1; #X connect 7 0 6 0; #X connect 8 0 0 0; #X connect 9 0 0 1; #X connect 10 0 0 0; #X connect 11 0 0 1; #X connect 12 0 8 1; #X connect 12 0 9 1; #X connect 12 0 10 1; #X connect 12 0 11 1;
#N canvas 298 82 155 84 10; #X obj 4 230 tabwrite~ $0-table; #X obj 4 266 table $0-table $1; #X text 5 83 $1 = length in samples; #X obj 4 104 inlet~ signal; #X obj 274 407 tabread4~ $0-table; #X obj 274 326 *~ $1; #X obj 273 300 phasor~; #X obj 273 271 expr 1/$f1; #X obj 273 124 f $1; #X obj 273 148 / 44100; #X obj 273 97 loadbang; #X obj 274 352 +~ 1; #X obj 274 490 outlet~; #X obj 2 22 tgl 20 0 $0-s_ctrl_rec $0-r_ctrl_rec REC 3 10 0 10 -66577 -258699 -262144 0 1; #X obj 110 128 sel 0 1; #X text 329 135 get length (secs); #X msg 132 155 bang; #X msg 93 155 stop; #X obj 132 204 delay; #X obj 162 182 * 1000; #X obj 110 102 r $0-s_ctrl_rec; #X obj 132 284 s $0-r_ctrl_rec; #X msg 377 271 0; #X obj 48 25 hsl 100 12 0 441000 0 0 $0-s_ctrl_playhead $0-r_ctrl_playhead Playhead 10 6 0 10 -66577 -258699 -262144 691 1; #X msg 338 97 bang; #X obj 2 62 nbx 5 14 -1e+37 1e+37 0 0 $0-s_ctrl_speed $0-r_ctrl_speed play_length 0 -6 0 10 -66577 -195568 -1 10 256; #X obj 72 62 bng 15 250 50 0 $0-s_ctrl_reset $0-r_ctrl_reset reset 0 -6 0 10 -66577 -195568 -1; #N canvas 0 0 450 300 playhead_control 0; #X obj 134 127 s $0-r_ctrl_playhead; #X obj 134 103 snapshot~; #X obj 134 79 metro 10; #X obj 134 55 loadbang; #X msg 199 55 bang; #X obj 18 52 inlet~ signal; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X connect 4 0 2 0; #X connect 5 0 1 0; #X restore 298 384 pd playhead_control; #N canvas 0 0 450 300 speed_control 0; #X obj 44 28 inlet length_secs; #X obj 44 186 outlet length_secs; #X obj 76 118 s $0-r_ctrl_speed; #X obj 76 90 f; #X obj 108 146 r $0-s_ctrl_speed; #X obj 104 65 r $0-s_ctrl_reset; #X obj 65 146 sel 0; #X connect 0 0 3 0; #X connect 3 0 2 0; #X connect 4 0 6 0; #X connect 5 0 3 0; #X connect 6 1 1 0; #X restore 297 212 pd speed_control; #N canvas 0 0 450 300 defaults 0; #X obj 20 12 loadbang; #X obj 20 97 s $0-r_ctrl_env; #X msg 20 72 20; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 11 298 pd defaults; #N canvas 520 265 450 398 envelope 0; #X obj 28 265 outlet~; #X obj 29 14 inlet~ phasor; #X obj 28 178 threshold~; #X obj 57 44 r $0-s_ctrl_env; #X obj 28 239 line~; #X obj 28 213 pack 0 f; #X obj 93 213 pack 1 f; #X obj 57 94 expr 1-$f1; #X msg 57 153 set $1 0 $2 0; #X obj 57 124 pack f f; #X obj 168 203 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 192 203 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 117 176 0; #X msg 149 176 1; #X obj 57 68 / 4410; #X connect 1 0 2 0; #X connect 2 0 5 0; #X connect 2 0 10 0; #X connect 2 1 6 0; #X connect 2 1 11 0; #X connect 3 0 6 1; #X connect 3 0 5 1; #X connect 3 0 14 0; #X connect 4 0 0 0; #X connect 5 0 4 0; #X connect 6 0 4 0; #X connect 7 0 9 0; #X connect 8 0 2 0; #X connect 9 0 8 0; #X connect 12 0 2 1; #X connect 13 0 2 1; #X connect 14 0 7 0; #X connect 14 0 9 1; #X restore 296 432 pd envelope; #X obj 274 456 *~; #X obj 106 63 nbx 3 14 0 1e+37 0 0 $0-s_ctrl_env $0-r_ctrl_env window 0 -6 0 10 -66577 -166441 -1 20 256; #X obj 141 248 s $0-r_ctrl_env; #X obj 393 98 inlet b_synch; #X connect 3 0 0 0; #X connect 4 0 31 0; #X connect 5 0 11 0; #X connect 6 0 5 0; #X connect 6 0 30 0; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 9 0 7 0; #X connect 9 0 19 0; #X connect 9 0 28 0; #X connect 10 0 8 0; #X connect 11 0 4 0; #X connect 11 0 27 0; #X connect 14 0 17 0; #X connect 14 1 16 0; #X connect 14 1 22 0; #X connect 16 0 0 0; #X connect 16 0 18 0; #X connect 17 0 0 0; #X connect 18 0 21 0; #X connect 18 0 22 0; #X connect 18 0 33 0; #X connect 19 0 18 1; #X connect 20 0 14 0; #X connect 22 0 6 1; #X connect 24 0 8 0; #X connect 28 0 7 0; #X connect 30 0 31 1; #X connect 31 0 12 0; #X connect 34 0 22 0; #X coords 0 0 1 1 175 65 1;