One more grain sampler
I have added pitch shift control.

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

I ditched Arch and my custom preemptive kernel and am using Ubuntu 9.04 X86_64 with the linux-rt kernel. looks like it works well again.

> Maybe I'll post it once I do some fine-tuning.

Please do. It should be interesting.

The disadvantage of using writesf~ is that you're using the computers disk which is far slower than ram. Depending on the machine this might cause performance issues. One way to get around this on linux is to use RAMFS or TMPFS. It lets you use a chunk of ram as if it were a disk, allowing you to "save" file there.

http://en.wikipedia.org/wiki/TMPFS

There is a way to do this on OS X: http://lists.apple.com/archives/darwin-kernel/2004/Sep/msg00004.html as well.

ok guys, i tweaked this up for you this morning, i've been neglecting Pd lately and I need to get back into it so here's a cool patch i came up with a while ago, that i made a quasi-tutorial for, and some masssssssive description (hey, i can't help it, i like being thorough). if you have any questions about the specifics don't hesitate to ask - i gave a general overview of how everything works but if you want to know specifics about the guts of the patching (especially since i'm not exactly the most aesthetically pleasing patcher out there) i can go into more detail.

included are the three main patches, sampgran.pd, vid01.pd, and seq16step.pd, with a few small abstractions they need. also included are a .mov and .avi included with gem so you can test it if you don't have any video clips handy, a small beatloop .wav to load into the granulizer, and a small sequence file named sequencing.sequence

the gist is it's a simple looping sampler using a phasor~ as a sawtooth lookup - a great technique for looping samplers that i thought one day, "why don't i just scale the phasor~'s output to a video the same way i scale it to an array with a soundclip?" and guess what - it worked, pretty damn good at that. i also had a (still) work-in-progress granulizer based on that sampler, and after rearranging some amens and watching homer dance around in time, i decided to try adding the same patching to the granulizer, with some pretty cool results.

it does need some work - with a short trigger time when you adjust the initial playback speed control, essentially just pitch shifting the loop without changing the speed, there's no real visible effect on the video. i need to figure out some additional effect i can do with it, maybe a blur or something... considering a short soundclip is at least 100k samples long, and the clips i was using with were less than 100 frames long for the most part, you can see why there'd be a bit more room to work with in the soundfile than the video - but even so, there's some obvious sync there when you tweak it out, and it was a shitload easier to get working than i thought it would.

anyways, open the long titled RUN ME FIRST .pd file and it'll load everything up for it. there's a quick start guide on bottom of the main window where it tells you how to load files in - i decided not to set it up automatically so that way if you wanted to use them on their own you'd know how to use them. LET ME KNOW if you have any problems - someone's tested it for me but i might've missed something.

there you have it, sampgran.pd combined with vid01.pd. LONGEST POSTS EVARRR

http://www.pdpatchrepo.info/hurleur/slvmchn-video-granulizer.rar

trying to get arduino to work with my linux distro...

Checked /var/log/messages and it says:

kernel: usb 1-2: new full speed USB device using ohci_hcd and address 4
kernel: usb 1-2: configuration #1 chosen from 1 choice
kernel: usbcore: registered new driver usbserial
kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
kernel: usbcore: registered new driver usbserial_generic
kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core
kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
kernel: ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
kernel: drivers/usb/serial/ftdi_sio.c: Detected FT232BM
kernel: usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
kernel: usbcore: registered new driver ftdi_sio
kernel: drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver

All looks fine....

The problem seems to be that I can't select the serial port number using "Comport" inside the "Arduino" abstraction, tried giving it a file path using the devicename message /dev/usb/ttyUSB0 but no luck.

Any ideas?

...seriously (serialously?) this is doing my head in...

A question to all you linux users out there;

What's the best way to configure alsa? I have a Layla24 and there are device drivers in the kernel source. Should I configure my kernel so that ALSA and my drivers are included in the Kernel, or loaded as modules? If I compile my kernel with these as modules and

# modprobe snd-Layla-24

will it work? And what is with the alsa-firmware? Where does the firmware go? Is this a module as well?

(One more hairy point; my device is pcmcia. not pci. and the drivers seem to live in /etc/modules..../pci)

Sorry about all the question marks.

Nestor

Hi

I have an AMD64 right now, and I don't think I can really that headaches it has caused me. Although the distros has inproven a lot for 64 bit, it's still not at a place where I would recommend you use it for audio work.
Since kernel 2.6.10 lots of things were easier to compile (I have no idea if this was just my perception or if actual improvements had been implemented). Pd 0.38 will compile in a 64 bit fc3, but not many externals will Maxlib definately wont. TAP plugins are fine but SWH plugins wont. The newest Ardour will but Muse wont. Oh, and audacity is actually compiled for 64 bit.
The hard thing is, that it is really a trial thing to find out, and you still have to know that most audio programs is written for 32 bit anyway, so you won't actually be using the extra processor power for them.
Even though I would love to be experiment with the extra computer power I took some advice from the CCRMA mailing list and just switched to 32 bit fc3 with the CCRMA kernel. You will just get more work done instead of continuingly struggling to just getting things to work and that's what it's about at the end of the day anyway.
There's some hope however. There's something called 64 studio or something to that effect. It's still in the developing stage and I believe it's a commercial product, but check it out.

Should you decide to give it a try, I would like to know if have any more luck than I did.

Good Luck.

Hello!

I connected my USB MAudio Midisport 2x2 and installed the proper driver. It is soundcard 3.
/proc/asound/cards:

0 [I82801DBICH4 ]: ICH - Intel 82801DB-ICH4
Intel 82801DB-ICH4 at 0xf4fff800, irq 7
1 [VirMIDI ]: VirMIDI - VirMIDI
Virtual MIDI Card 1
2 [Modem ]: ICH - Intel 82801DB-ICH4 Modem
Intel 82801DB-ICH4 Modem at 0xb400, irq 7
3 [M2x2 ]: USB-Audio - MidiSport 2x2
M-Audio MidiSport 2x2 at usb-0000:00:1d.0-1, full speed


The Ouptup of: aconnect -io:

client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 72: 'Virtual Raw MIDI 1-0' [type=kernel]
0 'VirMIDI 1-0 '
client 73: 'Virtual Raw MIDI 1-1' [type=kernel]
0 'VirMIDI 1-1 '
client 74: 'Virtual Raw MIDI 1-2' [type=kernel]
0 'VirMIDI 1-2 '
client 75: 'Virtual Raw MIDI 1-3' [type=kernel]
0 'VirMIDI 1-3 '
client 88: 'MidiSport 2x2 - Rawmidi 3' [type=kernel]
0 'MidiSport 2x2 MIDI 1'
1 'MidiSport 2x2 MIDI 2'

How can I find out what midiindev I have to use?

Thank you a lot.

fixed all my ALSA drop-outs by doing (as root):

# echo "1" >/proc/sys/kernel/lowlatency

To activate the low latency patch (for some reason it wasn't activated, so the kernel wasn't really low latency at all...)

# gedit /etc/sysctl.conf

add the line

kernel.lowlatency = 1

To activate it permanently.

To enable realtime priority: WARNING: BIG SECURITY HOLE

# chown mynormaluser:mynormalgroup /usr/bin/pd
# chmod u+s /usr/bin/pd

Now I can run Pd with -rt and even under heavy load Pd never clicks or skips or drops out - perfect operation!

I still haven't set up Jack...


wow
have to try
many thx thx thx...

I fixed all my ALSA drop-outs by doing (as root):

# echo "1" >/proc/sys/kernel/lowlatency

To activate the low latency patch (for some reason it wasn't activated, so the kernel wasn't really low latency at all...)

# gedit /etc/sysctl.conf

add the line

kernel.lowlatency = 1

To activate it permanently.

To enable realtime priority: WARNING: BIG SECURITY HOLE

# chown mynormaluser:mynormalgroup /usr/bin/pd
# chmod u+s /usr/bin/pd

Now I can run Pd with -rt and even under heavy load Pd never clicks or skips or drops out - perfect operation!

I still haven't set up Jack...