Hi,
I have some problems with a live looper patch I am building for my band.
My question is: Is it possible to copy the content of an array into another array (or reset all entries to zero) directly by using messages? If so what messages?
Raffael
On 2010-10-27 10:22, Raffael Seyfried wrote:
Hi,
I have some problems with a live looper patch I am building for my band.
My question is: Is it possible to copy the content of an array into another array (or reset all entries to zero) directly by using messages? If so what messages?
resetting to 0 can be done by sending the "const 0" message to the array.
copying the array cannot be done directly, you could either use:
a) pd-vanilla | [t f f ] | | [tabread from] | | | [tabwrite to ]
b) zexy's [tabdump] [bang( | [tabdump from] | [list prepend set 0] | [list trim] | [s to]
c) iem_tab's [tab_copy]
mfgasdr IOhannes
Hi Raffael,
Keep in mind that copying between arrays at faster than audio speed may give the same kind of glitches you get when you use [soundfiler] to load audio into an array. For this reason I wouldn't recommend it during a live performance.
My recommendation would be to either use several arrays which you can switch between, or make one long array and switch between active "zones" in the array for different loops. STEIM's LiSa live-sampling program takes the second approach, by the way...
Best! Derek
On 10/27/10 10:49 AM, IOhannes m zmoelnig wrote:
On 2010-10-27 10:22, Raffael Seyfried wrote:
Hi,
I have some problems with a live looper patch I am building for my band.
My question is: Is it possible to copy the content of an array into another array (or reset all entries to zero) directly by using messages? If so what messages?
resetting to 0 can be done by sending the "const 0" message to the array.
copying the array cannot be done directly, you could either use:
a) pd-vanilla | [t f f ] | | [tabread from] | | | [tabwrite to ]
b) zexy's [tabdump] [bang( | [tabdump from] | [list prepend set 0] | [list trim] | [s to]
c) iem_tab's [tab_copy]
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 27 Oct 2010, Derek Holzer wrote:
Keep in mind that copying between arrays at faster than audio speed may give the same kind of glitches you get when you use [soundfiler] to load audio into an array. For this reason I wouldn't recommend it during a live performance.
It's not precisely the same situation, because you don't have to wait for the hard disk. RAM-to-RAM copying is usually a thousand times faster than that, or better. So, you won't encounter problems at the same size of array than for [soundfiler], and the size won't even be anything close to similar.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
Am 27.10.2010 16:01, schrieb Mathieu Bouchard:
On Wed, 27 Oct 2010, Derek Holzer wrote:
Keep in mind that copying between arrays at faster than audio speed may give the same kind of glitches you get when you use [soundfiler] to load audio into an array. For this reason I wouldn't recommend it during a live performance.
It's not precisely the same situation, because you don't have to wait for the hard disk. RAM-to-RAM copying is usually a thousand times faster than that, or better. So, you won't encounter problems at the same size of array than for [soundfiler], and the size won't even be anything close to similar.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks,
the tab_copy option worked best for my patch so far.
From experience, I can say that [tab_copy] and [tabdump] do cause problems when moving audio files around during performance. Whether that is justified by a theoretical explanation or not....
D.
On 10/27/10 4:01 PM, Mathieu Bouchard wrote:
On Wed, 27 Oct 2010, Derek Holzer wrote:
Keep in mind that copying between arrays at faster than audio speed may give the same kind of glitches you get when you use [soundfiler] to load audio into an array. For this reason I wouldn't recommend it during a live performance.
It's not precisely the same situation, because you don't have to wait for the hard disk. RAM-to-RAM copying is usually a thousand times faster than that, or better. So, you won't encounter problems at the same size of array than for [soundfiler], and the size won't even be anything close to similar.
On Thu, 28 Oct 2010, Derek Holzer wrote:
From experience, I can say that [tab_copy] and [tabdump] do cause problems when moving audio files around during performance. Whether that is justified by a theoretical explanation or not....
The LED of the hard disk isn't very theoretical...
The speed difference is also not very theoretical...
If you had that much experience, you'd say that it's true that [soundfiler] causes problems with smaller table sizes than [tab_copy] does, and you wouldn't need any frigging theory to say it.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Wed, 27 Oct 2010, IOhannes m zmoelnig wrote:
a) pd-vanilla [tabread from] [tabwrite to ] b) zexy's [tabdump] c) iem_tab's [tab_copy]
d) GridFlow's
[#for 0 1024] | [t a a] | `----------. [#tabread from] | | | [#tabwrite to]--'
Just like vanilla's except you don't have to make a counter on your own (which was not drawn by Johannes in his example). replace 1024 by your array's size (or feed it in middle inlet).
This is much faster than the vanilla equivalent because it only sends 3 messages in total instead of 3 times the number of elements. It's basically as if you could "compile" your vanilla message-system patch.
For older versions of [#for], add a '1' argument as the step size ($3), because it didn't have a default value.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Wed, Oct 27, 2010 at 09:59:06AM -0400, Mathieu Bouchard wrote:
On Wed, 27 Oct 2010, IOhannes m zmoelnig wrote:
a) pd-vanilla [tabread from] [tabwrite to ] b) zexy's [tabdump] c) iem_tab's [tab_copy]
d) GridFlow's
[#for 0 1024] | [t a a] | `----------. [#tabread from] | | | [#tabwrite to]--'
e) The "BSP method":
[tabplay~] | [tabwrite~]
optionally in an upsampled subpatch.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
-
Derek Holzer -
Frank Barknecht -
IOhannes m zmoelnig -
Mathieu Bouchard -
Raffael Seyfried