Sorry if this is off topic to the full duplex question specifically, but I'm curious to see which embedded/dev/sbc board people have had the most success with in regards to Pd.

My initial work with the RPi was when it came out, and Pd wasn't too hot. I understand it has gotten leagues better, but I'm curious to see what the best board is for Pd.

Hi, everyone.

I recently came into possession of an original Xbox for free. I did a softmod, and got it working with emulators and that type of stuff. But what I really want is to get Linux working so I can run PD on it.

My broader issue is that resources for using linux on original XBoxes have dried up. Outdated guides, expired domains, and download links 404ing. I've managed to get some stuff working, but issues persist. I got xDSL running, but apt-get install puredata won't work. Getting dependencies is tricky, because the repos are old. Updating the repo locations helps, but doesn't get me all the way there. On and on. I tried switching my efforts to Xebian, but that looks like its going to need a little elbow grease as well.

I was looking for an older version of Dynebolic, which supposedly has Puredata included. But I can't for the life of me find a working link for v1.4 (the last version that supported the original XBox).

I know specific guidance might be a little much to ask. But I wanted to know if anyone had successfully pulled this off in the past, and if there was any general advice that might help me along. Distros that worked for you? Methods for installing/running Pd? Things to look out for?

It would be great to make this thing a little Pd box instead of just donating/re-selling it. Any wisdom from someone who has pulled it off?

Using notein and poly to control an arduino

For starters, my flow is as follows:
Ableton Live (any DAW will do) sends MIDI data to Puredata
Puredata uses a [notein] and [poly] to receive MIDI notes
An arduino with Firmata is setup, and a Pduino setup is implemented in the patch
The arduino receives this data to trigger RGB lights

I'm using RGB LEDs, which can achieve Yellow, Cyan, Magenta and White via color mixing. So I can control the pins on the Arudino via PD just fine. If RGB are pins 1,2, and 3, I can create Magenta by turning on pins 1 and 3.

In theory: very cool. My hope it to make an arudino board and accompanying pd patch that I can give to a friend for his live shows. He can program the lights using a MIDI channel on his daw, without having to touch the Arduino or PD.

Problem:
I'm not sure if I'm using [poly] correctly.

For right now, I have 2 LEDs. I will eventually be using 4. Each of these LEDs has 3 inputs. When I setup everthing with one LED, it worked fine. But adding another LED has confused the process somewhat. If I want both LEDs to turn white at the same time, there will be 6 MIDI notes at the same time. So, [poly] should be given a value of 6, correct?

Now when I set [poly 6], and then try to make only one LED go all white (3 MIDI notes), instead of one LED being white and the other being off the values get split somehow. So one LED gets one "on" message, and turns green, while the other gets two "on" messages and turns magenta.

This might be a little hard to read. But I'm trying to get some ideas about how this setup might be able to work the way I'd like. I would prefer to not have 4 separate MIDI tracks for each light. I was considering doing some kind of parsing of MIDI information at [notein] usig [route] and then assigning one light to one chord. ie; C1 is light one, C2 is light two and so on. Each one of these would have it's own [poly] with a value of 3.

I'm not sure if that is going to work, however. I'm going to try to implement it and see if it works the way I'm imagining it.

For those who might not be working with Arudinos, Firmata, Pduino, etc, all I'm doing to enable these "pins" is bang a toggle box. Traditional PD logic should apply.

Open brainstorming is appreciated. Thanks for your help.

http://www.pdpatchrepo.info/hurleur/midi_to_lights_pduino.pd

Hey gang,

I'm using readsf~ to play back .wav files in a sequence. It's working well, except when playing the sequence there are clicks at the beginning/end of the samples. It's pretty noticeable.

Is there a technical issue with readsf~ that I should know about? Or should I just simply create a volume envelope that will cut off the clicks? The bpm for playback can get pretty high (don't care if the files don't play fully and get cut off), so I've avoided loading the wav into and array and then playing it back. Would loading to a table create noticeable lag?

Just trying to figure out the best way to patch this and keep it as quality as possible.

Thanks for any help.

Hi, I'm wondering if there is an object somewhere that would create a random list. I'd like to create a random string of numbers to send to an array instantly. So, everytime I banged I would send a random string of numbers within a set range and a set number of numbers.

I've been looking around and I haven't seen anything yet. I made a sort of kludge-y workaround but now that's acting up on me.

Any help? Does such an object exist?

I'm using [mp3play~] to trigger short samples. I've noticed that sending a stop message to kill the playback isn't too snappy. Noticeable delay.

So I was playing around with the pause message, because it's more immediate. But when I send a pause, then a stop, then re-open the mp3 file I'm trying to play and then re-start... it doesn't start at the beginning. It picks up where it left off.

I was thinking I could cut off the volume as an immediate stop, then sending the stop message to actually stop the thing. Or something of that nature.

Does anyone have any experience with [mp3play~] and it's quirks? Is there a message flow that works the best for rapidly playing and stopping mp3 clips? I'm currently sequencing small mp3 clips, so trigger lag isn't too much of an issue. But would it be feasible to have a live sampler that used mp3 files instead of wav?

Any help, thoughts, discussion appreciated.

I'm currently building something with an arduino and pd. Arduino vets- help is appreciated!

So, I'm using [comport] and [convert.ascii2pd] to read inputs from an arduino. I'm not using pduino, firmata, etc. because I'm multiplexing the input.

I have a multiplexer read 8 potentiometers going into 1 analog input on my arduino. So I rapidly read all 8 of the inputs in a loop and print them out over serial.

My problem is I don't know how to take this stream and put it to an array properly. Out of [comport] to [convert.ascii2pd] to printing the results looks like this:

print: 790
print: CR
print: LF
print: 0
print: CR
print: LF
print: 0
print: CR
print: LF
print: 0
print: CR
print: LF
print: 703
print: CR
print: LF
print: 649
print: CR
print: LF
print: 547
print: CR
print: LF
END: bang

I'm seperating the values with special characters, which can be weeded out with [route] if need be. I have the end of each 8 input read banging.

But it's late and my head is reeling. Not sure where to start next in terms of putting these properly in a list or an array. The end goal being that I have 8 potentiometers that can control things in pure data. Any way to make sense of this input?

The things we do for more inputs!

So I was working on a patch, and PD crashed. I hadn't saved right before, but I hadn't done that much work on the patch so I wasn't to stressed out about it.

I re-opened the patch and everything is crazy. All of my objects are in completely different spots. The connections are all wired together differently, and it's all a crazy web-like mess. There doesn't seem to be any rhyme or reason to the re-arrangement.

It's frustrating, but it was so surprising and ridiculous that I almost started laughing when I saw it. It sucks because now I'm going to have to re-build the whole thing.

Has anyone heard of this? How can I make sure this doesn't happen again? Or is it just a fluke?

Working on Windows Vista, PD 0.41.4 extended, using a custom abstraction and the ~mp3play external, running ASIO4ALL.

Quick question: how is your RPi set up? I've had a horrible time trying to get ALSA playing nice with PD. I now have a USB sound card in the mix (Conectiv), but it's not working in PD.

The RPi seems like the perfect host for PD. Especially once you get your patch all set and you can just run it from the command line... man. Makes me wish the sound would work better out of the box.

I've actually been using that. Certainly helpful to get started.

I've *somewhat* solved the problem. Using his tutorial as a base, what I wound up doing instead what routing the raw MIDI values.

So instead of setting up
[notein]
| \
| \
[poly 4]
| \ \
[pack f f f]
|
[route 1 2 3 4]
| | | |
( voices )

I 'hard coded' the values, so to speak.
[notein]
| \
| \
[poly 4]
\
[route 34 35 36 37]
| | | |
( bangs )
| | | |
( toggles )

and this works without note on and off, because there will be a bang for note on and note off. So this turns on the toggles appropriately, so far.

I've had some weird bugs that I haven't been able to replicate. But when I zero in on what is happening I'll make sure to post an update. But for now, this (tentatively) works with all 12 pins and corresponding toggle boxes that I need.