Hi everyone!

Thanks to you all for this great forum.
I sure learned a lot here! I'm glad to finally present some work of mine, too...

ALFALOOP is a dynamic looper I've developed with PD Vanilla 0.42.6.
I call it a "non-sticky looper" since it allows you to change its loop-length at any time.

ALFALOOP let's you do basically anything related to looping, such as:

• super short loops of a few milliseconds (that would be a delay...)
• volume-control of the loop in a delayish way (feedback). This results in a "forgettable" looper.
• recording while overdubbing and vice-versa
• free time-shift (make your loop shorter/longer, incl. adjustment of the level of the previous recordings)
• sidechain-compressing of the loop by the input-signal
• proper latency-correction
• etc...

ALFALOOP has four main-buttons: recording, overdubbing, feedback and ducking.
If you assign these four buttons to midi-controllers, you don't need to watch the computers
screen. Everything can be achieved by using these four controllers. You can assign midi or key controllers simply by "touching" like in Ableton and such.

There are plenty of settings-parameters to play around with, like:

• crossfade-length
• crossfade-offset
• fade-in/out-time of the input-signal
• fade-in/out-time of the previous recording while overdubbing (ducking-level)
• automated overdubbing (threshold)
• pre-recording-time (like: 50ms before you hit your controller, scary, isn't it?)
• etc..
  All the settings get stored automatically.

My goal was that people with little knowledge of PureData (or computers in general) can easily use it too. ALFALOOP features a lot of on-screen-info.
To make sure the GUI looks more or less the same on every platform only canvases were used as visible gui-objects. I did my best to clean everything up and make it look neat...

The main-engine is a built out of a mixture of delays and tables. In a future release, I will document the subpatches.

There is still a lot to do, of course. But now I feel more like making some music...

You can download ALFALOOP and get some further information at:

https://www.marcobaumgartner.com/#puredata/ALFALOOP

Have fun!

Marco

http://www.pdpatchrepo.info/hurleur/ALFALOOP_0.1.2.zip

@bassik said:

In this case I don't really get the point why you are researching the exact sample value of the peak value. In my experience, analysis of simple IR don't give substantial different results if the time zero of the IR is not exactly on the peak

Some more experimenting has learned me that it depends on the system under test. For an IR of the MacBook internal soundcard loopback, the problem is manifest. For an IR of my room, that is not the case. The difference is probably this: the soundcard's spectrum is near to perfect and there is only a direct response. The room test response missed a lot of the low spectrum end (also due to lousy 'test equipment'), and the direct response is buried in reflections because of the small room size. It's funny that the room response is much easier to trim than the loopback response.

Searching the internet I found the name for the phenomenon: fractional delay. And of course implementations for fractional delay, which can also be used to get rid of fractional delay. As far as I can see now, we'll only need it for cases where the direct response has a prominent role. For example, when we want to produce inverse filters for correction of spectral deficiencies in test equipment. We're not at that point yet.

Anyway, I did a patch with a model of fractional delay, which clearly illustrates the problem. (See attachment). And if you do a loopback test with [IRrecorder], you'll see what I mean as well.

edit: bah, again impossible to attach file. (Did I exceed my upload quotum?). It's here:

http://www.katjaas.nl/temp/fractional-delay.pd.zip

Katja

Hi,

The attached patch dsdelay is supposed to be a variable delay line with a moving write point. vd~ uses a moving read point which is acceptable for most applications but not what I am working on. I have implemented my moving write point delay line in MATLAB and it works reasonably well. However I am experiencing issues with PD implementation.

The patch uses a table to store the delay line values and is supposed to use a circular delay line method (i.e. the read/write points shift with time instead of the actual elements of the delay line). The intention is that the read point shifts along the delay line by one sample per sample, and the write point does the same whilst the delay is not being altered. The write point uses a simple two point extrapolation to allow writing at fractional table indices.

I'm having two problems:

1. I can't find a satisfactory method of wrapping signal values in an arbitrary range. I want to be able wrap a signal value between 0 and 44100 for example, but using

|
[/~ 44100]
|
[wrap~]
|
[*~ 44100]
|

gives rise to rounding errors which create artifacts in the output. This is why in the current state, the output is intermittent rather than continuous.

2. For some reason the 2 point extrapolation seems to be not working correctly. I'm getting a ring modulation type effect on the output. In MATLAB the addition of the two point extrapolation helped to minimise artifacts when the delay time was being altered. Altering the delay time gives rise to horrible artifacts at the moment though.

Any pointers on how to get this working properly would be greatly appreciated.

Thanks

Ben

http://www.pdpatchrepo.info/hurleur/test.zip

For hardware interfaces, check these out:
http://www.anyma.ch/research/udmx/
http://www.opendmx.net/index.php/Open_DMX_USB
http://www.opendmx.net/index.php/DMX_USB_Pro
http://www.enttec.com/index.php?main_menu=Products&pn=70304&show=description&name=dmxusbpro
http://www.opendmx.net/index.php/DMXking_USB_DMX512-A
http://www.dmx4all.de/index.html
http://www.skpang.co.uk/catalog/product_info.php?cPath=140_142&products_id=663

Haven't tried any yet, but I'm gearing towards anyma uDMX, because they have Pd examples up on the website.

As for the exact DMX commands you're looking for, I don't have a clue, just getting into the protocol myself. This could be a good intro:
http://www.arduino.cc/playground/Learning/DMX

Greetings all,

I have just posted a collection of student patches for an interaction design course I was teaching at Emily Carr University of Art and Design. I hope that the patches will be useful to people playing around with Pure Data in a learning environment, installation artwork and other uses.

The link is: http://bit.ly/8OtDAq
or: http://www.sfu.ca/~leonardp/VideoGameAudio/main.htm#patches

The patches include multi-area motion detection, colour tracking, live audio looping, live video looping, collision detection, real-time video effects, real-time audio effects, 3D object manipulation and more...

Cheers,
Leonard

http://www.VideoGameAudio.com

Pure Data Interaction Design Patches

These are projects from the Emily Carr University of Art and Design DIVA 202 Interaction Design course for Spring 2010 term. All projects use Pure Data Extended and run on Mac OS X. They could likely be modified with small changes to run on other platforms as well. The focus was on education so the patches are sometimes "works in progress" technically but should be quite useful for others learning about PD and interaction design.

NOTE: This page may move, please link from: http://www.VideoGameAudio.com for correct location.

Instructor: Leonard J. Paul
Students: Ben, Christine, Collin, Euginia, Gabriel K, Gabriel P, Gokce, Huan, Jing, Katy, Nasrin, Quinton, Tony and Sandy

GabrielK-AsteroidTracker - An entire game based on motion tracking. This is a simple arcade-style game in which the user must navigate the spaceship through a field of oncoming asteroids. The user controls the spaceship by moving a specifically coloured object in front of the camera.
Features: Motion tracking, collision detection, texture mapping, real-time music synthesis, game logic

GabrielP-DogHead - Maps your face from the webcam onto different dog's bodies in real-time with an interactive audio loop jammer. Fun!
Features: Colour tracking, audio loop jammer, real-time webcam texture mapping

Euginia-DanceMix - Live audio loop playback of four separate channels. Loop selection is random for first two channels and sequenced for last two channels. Slow volume muting of channels allows for crossfading. Tempo-based video crossfading.
Features: Four channel live loop jammer (extended from Hardoff's ma4u patch), beat-based video cross-cutting

Huan-CarDance - Rotates 3D object based on the audio output level so that it looks like it's dancing to the music.
Features: 3D object display, 3d line synthesis, live audio looper

Ben-VideoGameWiiMix - Randomly remixes classic video game footage and music together. Uses the wiimote to trigger new video by DarwiinRemote and OSC messages.
Features: Wiimote control, OSC, tempo-based video crossmixing, music loop remixing and effects

Christine-eMotionAudio - Mixes together video with recorded sounds and music depending on the amount of motion in the webcam. Intensity level of music increases and speed of video playback increases with more motion.
Features: Adaptive music branching, motion blur, blob size motion detection, video mixing

Collin-LouderCars - Videos of cars respond to audio input level.
Features: Video switching, audio input level detection.

Gokce-AVmixer - Live remixing of video and audio loops.
Features: video remixing, live audio looper

Jing-LadyGaga-ing - Remixes video from Lady Gaga's videos with video effects and music effects.
Features: Video warping, video stuttering, live audio looper, audio effects

KatyC_Bunnies - Triggers video and audio using multi-area motion detection. There are three areas on each side to control the video and audio loop selections. Video and audio loops are loaded from directories.
Features: Multi-area motion detection, audio loop directory loader, video loop directory loader

Nasrin-AnimationMixer - Hand animation videos are superimposed over the webcam image and chosen by multi-area motion sensing. Audio loop playback is randomly chosen with each new video.
Features: Multi-area motion sensing, audio loop directory loader

Quintons-AmericaRedux - Videos are remixed in response to live audio loop playback. Some audio effects are mirrored with corresponding video effects.
Features: Real-time video effects, live audio looper

Tony-MusicGame - A music game where the player needs to find how to piece together the music segments triggered by multi-area motion detection on a webcam.
Features: Multi-area motion detection, audio loop directory loader

Sandy-Exerciser - An exercise game where you move to the motions of the video above the webcam video. Stutter effects on video and live audio looper.
Features: Video stutter effect, real-time webcam video effects

Ta Toxonic - I'll take a look at the patch tonight. Good of you to take the time. Apologies if I've misunderstood though, but I think what you're describing is not quite what I mean: The pitch shift is separated out from the delay time - you're running a pitch shift effect into a separate delay line, which is not going to give the same effect. The delay time will not shorten as the pitch rises. I'll take a look at your patch tonight though as I may have misunderstood what you're getting at.

Maelstorm - thanks also. I understand why the pitch changes on a delay pedal. The pitchshifter patch was a bit of a red herring - though of course it's the same principle. The difference between what you're (both, I think) talking about and what I'm talking about is the way that the pitch changes.

Assuming a stable C tone playing into the delay:
With the standard simple PD delay set up, if you move the read point of a vd~ then you get a glissando as it accellerates, a constant pitch change as it moves at constant speed. So if you turn the knob to change the delay time in the middle of a tone you start with a constant pitch (C), then get a rise of pitch, then it levels out at a new pitch (as you turn then stop turning the knob),
_
___/

If you feed back into the delay, the glissando is repeated as the read speed changed while the write speed was constant:
_ _ _ _
/ |/ |/ |/ |

The effect I'm looking to emulate on the other hand is more akin to changing the speed of a phasor~ reading an array - the pitch change is not a blip, but a stable interval's transposition - eg: you turn the knob, the pitch of the repeats rise by a given interval and stays at that pitch as it repeats (now more quickly):
______
___/

If you play a constant C tone, then speed up the delay until it is a major third higher, you get a major third diad (until the delay dies away), rather than a C tone with a repeating squiggle overlaid.
The effect is the same as you get by speeding up a tape loop delay (though the pedal I'm trying to imitate is a digital delay) which is why I think the rate of the write and read heads are being increased by the same amount.

[edit, just tried to make this clearer and removed a couple of errors]

I've been trying to emulate a delay pedal I have, but having no luck.
The effect I'm after is a stable interval's pitch change when you change the delay time - you can tune the sound going around the delay loop up or down by a stable number interval by shortening or lengthening the delay time - just as you could tune sample playback by changing the rate of a phasor~ reading an array.

If I use a vd~ reading from a delay line (as in the rotating tape head pitch shifter example, but with added recirculating feedback) I can get pitch change effects (pretty great pitch change effects tbh) but they're unstable - they keep rising or falling in pitch with each circulation as they get pitch shifted each time they go around the loop.

I figured one way to implement the effect would be to change the write speed and the read speed by the same amount (I'd guess this is how the pedal is doing it)- But I have no idea how to change the delay write speed in PD.
I thought of changing sample rate using block~ in a subpatch with the delay line but that doesn't seem to give the desired results (or in fact any sound at all - so I'm guessing you can't upsample a delay line).

Any ideas???

No sound out of this Oscar.

Here's a bit of the error message:

ch file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus13.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus16.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus16.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus14.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus14.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/zapa06.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav: No such file or directory
error: soundfiler_read: /home/pelao/Documentos/audio/loops/terminus15.wav:

But, it looks awesome.

Keep well ~ Shankar

transcomp~ uses transdetect~ to shape the initial attack and release of a signal.

Requires IEM's FIR~, fexpr~ and dbtorms~ which are provided in PD-Extended.
To work properly the transdetect folder should be added to PD's path.

Start by opening help-transcomp~.pd

01 Implementation:

transdetect~ works by using two pairs of envelope followers. The first pair
subtracts an envelope follower with a slow attack from an accurate follower,
the result of which is a signal containing the initial attack. For the initial
release, the second pair subtracts an accurate envelope follower from one with
a slow release.

An envelope follower measures the mean square power of a signal over time
(see 3.audio.examples/H06.envelope.follower.pd for details on implementing an
envelope follower). To do this we must use a low pass filter at a very low
frequency. In order to achieve an accurate follower a linear phase FIR filter
was used (using IEM's FIR~ external). Unfortunately this introduces a phase
delay.

In order to facilitate the use of different envelope follower implementations,
transdetect~ requires a filter type as a creation argument implemented in
followernameTransDetectEF~.pd. 4 linear phase fir implementations are provided:
181, 251, 451 and 501 taps filters. The 501 taps filter provides the most
accurate filter but with a phase delay of 5.668 ms at 44.1kHz (raise the
sampling rate to lower the phase delay). They were all generating using
http://www.dsptutor.freeuk.com/FIRFilterDesign/FIRFiltDes102.html with a
cutoff frequency between 5 and 10 Hz.

A compromise between accuracy and phase delay might be achieved by using
minimum phase FIR filters. A 5th implementation using PD's native lop~ object
is also provided under the designation iir (FIR~ not required).

Along with different possible envelope follower implementation transdetect~
also requires an attack and hold type implemented in
attacknameTransDetectAttackShape~.pd and holdnameTransDetectHoldShape~.pd
respectively. These implementations dictate the kind of attack and release
curves used on the envelope followers (linear, slow[er|est] and fast[er|est]).
All implementations provided use fexpr~. A more efficient external could be
made to take fexpr~ place.

02 Use

In help-transcomp~.pd patch enable start and pay attention to the snap in the
hit. Disable the green toggle button to disable the compression make the snap
go away. Check out the tables on the left to see the results of the transient
compression.

transcomp~ is useful when used with recorded drums to maximize or minimize
its transient (to make it punchier or to make snare drums less clappy).

transcomp~ uses transdetect~. By itself transdetect~ can be used to synthesis
hits from a recording. For example, take a bass drum recording and use the
signals generated by transdetect~ to shape the frequency and envelope of a
synthesized kick drum.

Would love to have some feedback and some help in turning the linear phase filters into minimum phase filters.

http://www.pdpatchrepo.info/hurleur/transdetect.rar

Here's how it goes on OSX, with gcc, make and wget from fink.

wget http://www.lua.org/ftp/lua-5.1.3.tar.gz
--22:54:35--  http://www.lua.org/ftp/lua-5.1.3.tar.gz
           => `lua-5.1.3.tar.gz'
Resolving www.lua.org... done.
Connecting to www.lua.org[87.237.62.181]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 215,817 [application/octet-stream]

100%[====================================>] 215,817      196.24K/s    ETA 00:00

22:54:36 (196.24 KB/s) - `lua-5.1.3.tar.gz' saved [215817/215817]

tar xzf lua-5.1.3.tar.gz
touch lua-5.1.3/unpack.stamp
make -C lua-5.1.3 macosx local
cd src && make macosx
make all MYCFLAGS=-DLUA_USE_LINUX MYLIBS="-lreadline"
gcc -O2 -Wall -DLUA_USE_LINUX   -c -o lapi.o lapi.c
lapi.c:8:20: error: assert.h: No such file or directory
lapi.c:9:18: error: math.h: No such file or directory
lapi.c:11:20: error: string.h: No such file or directory
In file included from /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.0.2/include/syslimits.h:7,
                 from /sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.0.2/include/limits.h:11,
                 from luaconf.h:11,
                 from lua.h:16,
                 from lapi.c:16:
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.0.2/include/limits.h:122:61: error: limits.h: No such file or directory
lapi.c: In function 'lua_pushstring':
lapi.c:459: warning: implicit declaration of function 'strlen'
lapi.c:459: warning: incompatible implicit declaration of built-in function 'strlen'
lapi.c: In function 'lua_getfield':
lapi.c:551: warning: incompatible implicit declaration of built-in function 'strlen'
lapi.c: In function 'lua_setfield':
lapi.c:665: warning: incompatible implicit declaration of built-in function 'strlen'
make[3]: *** [lapi.o] Error 1
make[2]: *** [macosx] Error 2
make[1]: *** [macosx] Error 2
make: *** [lua-5.1.3/build.stamp] Error 2