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.

Some more detail on issues:

I think using [poly] is having problems giving the correct "on" and "off" values for each individual midi note. Of course, when I say that [poly] is having problems... that really means I'm having problems using it correctly, haha.

This may be part of the problem with the wrong pins getting turned on and off. Note on/off is being triggered, but perhaps some element of lag or improper routing is making it get messed up and not turn the notes that I want on and off.

Ideally, I would like to have some kind of magical MIDI-in that shows me *everything* that is happening on a single MIDI channel.

Perfect! Yes, it exactly what I needed.

I needed 64 random values. I used [until] hooked up to a [random] then [tabwrite] like you suggested. Then I hooked up an incrementing number atom to the [until] to match the index input of the [tabwrite]. I re-zero the index number every time I bang.

Works like a charm. Thanks.

Look into and download ASIO4ALL. That will start to fix alot of sound issues with Puredata and Windows.

In addition to that, in the PD window, go to Media>Audio Settings and double check your input and output devices. When you get ASIO4ALL installed, that will be an option. But if you don't have anything there, make sure you pick your existing soundcard. Click Apply, then OK. Then double check that you've checked the "Compute Audio" box in the PD window, then try the Media>"Test Audio and MIDI" option.

If you hear crackling, clicking, and weird distortion no matter what you're putting through Puredata- you should install ASIO4ALL. Mac users have it pretty sweet with their audio drivers, as they seem to play well with PD. Windows folk like us usually need to get ASIO4ALL to iron out the kinks, most frequently if you're using a laptop.

Hopefully that helps.

Sorry for the late response!

I've attached the patch. Here is the basic code I'm using for the arduino. Goodluck!

void setup()

{

Serial.begin(9600);

}

void loop()

{
int inputArray [7];

//what you'll do now is read from your inputs, and then assign the values to cells in your inputArray

int i;
for (i = 0; i < 8; i = i + 1) {
Serial.print(inputArray_);
Serial.print(" ");
}
Serial.println();
delay(1);

//not sure if you need the delay, but essentially you're going as fast as possible.
//formatted lines of 8 values will be printed through the comport, which will be read by the patch I've attached.

}

http://www.pdpatchrepo.info/hurleur/arduino_interface.pd_

I could be dealing with at least 10 to maybe 14 or even 15 hours.

I guess it's actually not that bad. I might be able to scrounge up 10-ish gigs of space on the machine I'm using. I perhaps I'll make two versions of this system and measure the pros v cons.

Not sure if this is any help, but this I how I formatted the output of the comport and parsed the list sucessfully:

http://puredata.hurleur.com/sujet-5832-reading-multiplexed-input-streams-arduino

Saw your TED video, so maybe you've already solved this problem.

In my limited work with getting arduino and pd to play nice, I've found that things like pduino and firmata work great but can be restrictive. I had to multiplex inputs on my arduino, which doesn't play nice with something like firmata that automatically reads all the pin values.

It might be better to have each arduino on it's own [comport], and differentiate the arduinos that way. Dump pin values over each comport and keep reading it.

Here's the thread explaining what I did:
http://puredata.hurleur.com/sujet-5832-reading-multiplexed-input-streams-arduino

I'm a fan of your work.

Well, due to hard drive limits on the project that I'm working on I'm trying to avoid having to work with .wav files.

And there doesn't seem to be a lag starting the playback, just ending it. So in terms of triggering sounds, it works fine. It's just the killing and subsequent re-starting that gets a little laggy.

So I think I'm going to implement the mute/stop solution and see how that works. If there are issues, I might set up two instances of the mp3 player and "juggle" between the two. Otherwise I might just have to bite the bullet and go with your solution and figure out HD space some other way.

Firmata would be a bit overkill. You're probably making the right call. And only needing to read one pin makes it way more simple.

If you don't want to use firmata, use the [comport] object. Write an arduino sketch that reads your pin and prints the output to the serial connection.

Read up a bit on [comport] so you understand how everything works, but if I understand your setup correctly you'll wind up having something that looks like this:

Following up. Just needed a clear mind and a cup of coffee.

Instead of polling the multiplexer and separating the inputs with line breaks, I separated them with spaces and capped them off with a line break. This allowed me to dump a string of numbers separated by spaces into a

, which I could then [unpack] into 8 number atoms.

To sum it up: Comport, to ascii conversion, to a route that gets rid of the line break symbol, to a list, to an unpack, to 8 atoms.

I'm excited about this because it's pretty simple, and should scale to 64 inputs if I decide to double up on my 4051 multiplexer. Not sure if this is the best setup for say, 8 (or 64) piezos for a drum pad. Haven't tested the latency on something like that yet. But it'll be fine for a bunch of knobs and faders!

Hopefully this will help someone in the future. If there's a better way to do this, let me know!