Re: [PD] ESI Gigaport HD+ on RPI

[Thomas Grill]

Hey Antoine, thanks for your efforts - that's great news! gr~~~
--
Thomas Grill
http://g.org



Am 02.05.2013 um 17:20 schrieb Antoine Villeret:


Hi,

I got an ESI Gigaport HD+ to work on the RPi
8 outputs at 48kHz / 24bit, no input
with alsa backend
without dwc_otg.speed=1 option

I also tested ESI UGM6 (2 high-Z inputs, 2 line output)
It works well with alsa when input is disabled
I got lots of crackle with input enabled
I can't get it to work at all with dwc_otg.speed=1

I've updated the Wiki page

cheers

a

--
do it yourself
http://antoine.villeret.free.fr


2013/4/28 Antoine Villeret 
hi,

thanks for feedback
I bought yesterday  a Gigaport HD+
I hope it will work at least on my Ubuntu laptop
and I'll test it on RPi too and update the wiki page

I also bought at the same time a ESI UGM96 (2 Hi-Z input, 1 stereo  
output and 2 headphone out - but i don't how many separates outputs)  
to use on the Pi, I'm not sure it will work because the user manual  
doesn't say anything about USB and USB Audio class compliance while  
the HD+ manual does...


And yes, the UDJ6 works great on the pi, 6 outputs (a stereo  
headphone jack output and 4 RCA)


cheers

antoine

--
do it yourself
http://antoine.villeret.free.fr


2013/4/28 Julian Brooks 
Sorry,

Just noticed the question about the hub:
No hub - not sure why you're asking but if it's relevant the Pi was  
connected to 5.2v/2a power cable, and running most recent firmware.



On 28 April 2013 01:16, Julian Brooks  wrote:
Hi Antoine,

The one I added is the HD (not HD+).  This one has the same casing  
as the 'AG' so was hopeful but no, nada.


Initially thought the one I tested was broken as there was no sign  
of it on the pi.  Plugged it into my debian lappy and boom - all  
recognized and working. Pah.


Currently sat on the 'not sure what to do with pile'.  It would have  
been great; 6 outs for not much money (plus the recycling redundant  
technology thing).


You seem to have had good results from the 'UDJ' card which seems to  
be currently the other choice for multiple audio outs on the RPi?


Julian


On 27 April 2013 16:25, Miller Puckette  wrote:
I can't report about that but I have another compliant USB 1.1  
interface,
Edrol UA25, which I've never been able to get to work with a pi.  So  
I think
this is confirmation that that can indeed sometimes happen (if it  
were just

one of us perhaps it could have been a fluke).

cheers
M

On Sat, Apr 27, 2013 at 11:18:06AM +0200, Antoine Villeret wrote:
> hi all,
>
> someone added the ESI Gigaport HD+ as a "not working sound card"  
few days

> ago on http://puredata.info/docs/raspberry-pi
>
> I'm quite surprised because this sound card is USB Audio Class 1  
compliant
> and  USB spec version 1.1 compliant and also fully compatible to  
USB 2.0

> host controllers
>
> Moreover, I had a confirmation this sound card works on Linux and  
it's

> previous version ESI Gigaport Ag works on the Pi.
>
> Thus i was thinking Gigaport HD+ will work on the RPi;
> Who made the test ?
> Could you tell me more about the setup ? (mainly if you use a USB  
hub or

> not)
>
> Cheers
>
> a
>
>
> --
> do it yourself
> http://antoine.villeret.free.fr

> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd -> svg

[Jonathan Wilkes]

A few points:

* you can open svg in a browser
* you can _zoom_ svg in a browser for decent results (it's a vector drawing)
* in safari you can select text in an svg (but not Firefox because of a bug, 
although you can stil  it)
* much (but not all) of tk canvas has corresponding drawing instructions in 
svg.  unless i'm missing something the subset of tk canvas commands used by Pd 
all have corresponding instructions in svg

Here's what I want to do (in Debian Wheezy):
1) Open pd-extended
2) Create new patch
3) Create [f]
4) Right click to open up float-help.pd (PDDP revised version)
5) Click print and save to test.ps
6) in cli type:
pstoedit -f plot-svg test.ps test.svg

But I get this error:

 Warning: glyf overlaps cmap, truncating.

Anyone know what this means?  It ends up cropping the top and bottom of the 
patch.  Google search for the error doesn't help much.

In the future it'd probably be better to parse a *.pd file directly to convert 
to svg, but if I can convert a ps to svg like this I think I can script it and 
get some nice looking online searchable documentation with very little work. :)

-Jonathan


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

[Martin Peach]

On 2013-05-03 12:34, Julian Brooks wrote:

Ok - thanks for that, makes more sense now.

When I run the C code this happens:

"./jb_d6t_reader_ic3 0
...export file accessed, new pin now accessible
...direction set to output
./jb_d6t_reader_ic3: initialized:0
Write failed (5)
 >> Input/output error <<
...unexport file accessed, pin now inaccessible"

I've done my best to go through the code and make changes where appropriate.

Replaced D6T8L with DRT44L2 and changed packet size.
Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1
to 0 for rev1 board.

Weirdly I can't access the i2c bus anymore?
cat /dev/i2c*
cat: /dev/i2c-0: Input/output error
cat: /dev/i2c-1: Input/output error



Yes I get that too. (unless the sensor returns one byte it's probably 
normal) But "i2cdetect -y 1" still shows a sensor at 0x0A.
I run the code as "sudo ./d6t_reader 0", otherwise I don't have 
permission to set the GPIO pin.

I don't get any write errors though.
Are you writing to the correct i2c?
There are two places in the code that could throw the write error. Maybe 
change the message so you can tell which one it is.
Anyway the setup should work with the old code (only one sensor), the 
4051 circuit should have no effect on the communication betwen the Pi 
and one of the sensors, the select pin select which sensor receives the 
clock. So if the older code isn't working the circuit is wrong, 
otherwise the code is buggy.


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

[Julian Brooks]

Ok - thanks for that, makes more sense now.

When I run the C code this happens:

"./jb_d6t_reader_ic3 0
...export file accessed, new pin now accessible
...direction set to output
./jb_d6t_reader_ic3: initialized:0
Write failed (5)
>> Input/output error <<
...unexport file accessed, pin now inaccessible"

I've done my best to go through the code and make changes where appropriate.

Replaced D6T8L with DRT44L2 and changed packet size.
Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1 to
0 for rev1 board.

Weirdly I can't access the i2c bus anymore?
cat /dev/i2c*
cat: /dev/i2c-0: Input/output error
cat: /dev/i2c-1: Input/output error

Tried to follow the code to figure where it's falling down but I'm not
getting it.

Also do I still need 1 or 0 after './jb_d6t_reader_ic(n)? 1 seems to make
it to go into PEC spiral with no readings.

Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<

etc etc.

i2cdetect -y 0 also draws a blank.

Very best wishes,

Julian




On 3 May 2013 16:31, Martin Peach  wrote:

> On 2013-05-03 10:26, Julian Brooks wrote:
>
>> Hey Martin / all,
>>
> ..
>
>> This is what we have and aren't sure if it's correct
>>
>
> Yes it's a bit wrong...
>
>
>  16 to 3.3v RPi
>> 14 to SCL (sensor 1)
>>
>
> Yes, pin 3 is connected through to pin 13 when pin 11 is low, and to pin
> 14 when 11 is high. So it's actually sensor 2 on pin 14.
>
>
>  13 to SCL (sensor 2)
>>
>
> Is actually sensor 1
>
>
>  [Each SCL has 10k resistor and a feed of 3.3v from RPi]
>> 11 to  P1-11 (GPIO 17) - RPi
>>
>
> Yes, 11 selects which channel. 9,10, and 11 make up a 3-bit address which
> selects which of the 8 output channels is connected to the input on pin 3.
> If you only have 2 sensors the two extra selector pins must be set low.
>
>
>  10 to SDA (sensor 1)
>>
>
> 10 to Ground or another selector pin if you have more than 2 sensors
> The sensor data pins are connected directly to the RPi SDA pin, only the
> SCL line goes through the 4051.
>
>
>  9   to SDA (sensor 2)
>>
>
> 9 to Ground or another selector pin
>
>  7   to Ground
>>
>
> Also, 6 (Inhibit) must be low for the chip to function (this permits
> expanding to more than 8 channels by using more 4051s)
> Pin 8 to Ground
>
>
>  3   to SDA P1-03 (GPIO 0) - RPi
>>
>
> 3 to SCL RPi, you're switching the clock line, not the data
>
>
>
>> The power for the sensors is wired directly into 5v from the RPi.
>> The ground for the sensors is wired directly into the RPi.
>>
>>
> Martin
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] [RADICAL] use of biotechnology to integrate networked bodies and interactive dance

[Marco Donnarumma]

Dear Pd'rs,
the Xth Sense (made in Pd/Linux) is at the core of this large-scale
biophysical interactive dance project we premiere today in New York.

Some pics of the backstage at the bottom website link.

Feel free to distribute through your networks!
best wishes,

\


Rensselaer Arts PHD Candidate, Heidi Boisvert, premieres performance at
EMPAC that cultivates an expressive virtual world populated by corporeal
sounds and generative imagery from dancers' bodies.

TROY, NY - April 8th, 2013 - The Arts Department at Rensselaer Polytechnic
Institute announces the premiere of a  mechanomyogram (MMG) multi-media
production, "[radical] signs of life," on May 3rd at 4:00 pm and May 4th at
7:30 pm in Studio 2 at the Experimental Media and Performing Arts Center
(EMPAC). Through responsive dance, "[radical] signs of life" externalizes
the mind’s non-hierarchical distribution of thought. Music is generated
from the dancers‘ muscles and blood flow via biophysical sensors that
capture sound waves from the performers’ bodies. This data triggers complex
neural patterns to be projected onto multiple screens as 3D imagery. As the
audience interacts with the images produced, they enter into a dialogue
with the dancers.

The performance makes use of biophysical technology to integrate networked
bodies and interactive dance. It was conceived and directed by new media
artist and game designer Heidi Boisvert in collaboration with an
international team of artists, including Pauline Jennings (Choreographer),
Doug Van Nort (Sound Designer), Allen Hahn (Set & Lighting Designer), Raven
Kwok (Visual Designer), Amy Nielson (Costume Designer) and Marco Donnarumma
(Sensor Designer & Developer). The project features the Xth Sense (XS), a
biophysical sensor that detects and captures mechanical sound waves
produced at the onset of musculature contraction. For "[radical] signs of
life," a wireless network and stand alone armband was custom developed for
the XS by engineer MJ Caselden, and industrial designer, Krystal Pernaud.

The choreography for the hour-long performance will be composed in
real-time by five dancers from a shared movement database in accordance
with pre-determined rules. Outfitted with two wireless sensors each, the
dancers--Jennifer Mellor, Ellen Smith Ahern, Hanna Satterlee, Avi Waring
and Willow Wonder--will create patterns that dissolve from autonomous
polyrhythms to intersecting lines as they slip through generative video and
light.

"[radical] signs of life" was produced, in part, at Harvestworks with funds
from the Rockefeller Foundation’s New York City Cultural Innovation Fund
and the National Endowment for the Arts. The work was made possible through
generous support from the Rensselaer Arts Department along with iEAR
Studios, and EMPAC staff. Rehearsal space was granted by an Artistic
Residency at the Contemporary Dance and Fitness Center in Montpelier,
Vermont.

Limited Seating. Reservations recommended. To make reservations, please
contact the EMPAC Box Office at 518.276.3921.

Media Contact:
Heidi Boisvert, heidijboisv...@gmail.com, +.1.917.536.2792
Full press package available upon request.
Or visit our project site: www.radicalsignsoflife.tumblr.com.


--
Marco Donnarumma
New Media + Sonic Arts Practitioner, Performer, Teacher, Director.
Embodied Audio-Visual Interaction Research Team.
Department of Computing, Goldsmiths University of London
~
Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com
Director: http://www.liveperformersmeeting.net
___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

[Julian Brooks]

Hey Martin / all,

Oh there's much chin scratching and head shaking going on at our end atm...

Can we ask if we have the hardware configured correctly before moving onto
software issues please:

Attached is the diagram of our 4051 mux'er.

This is what we have and aren't sure if it's correct
16 to 3.3v RPi
14 to SCL (sensor 1)
13 to SCL (sensor 2)
[Each SCL has 10k resistor and a feed of 3.3v from RPi]
11 to  P1-11 (GPIO 17) - RPi
10 to SDA (sensor 1)
9   to SDA (sensor 2)
7   to Ground
3   to SDA P1-03 (GPIO 0) - RPi

The power for the sensors is wired directly into 5v from the RPi.
The ground for the sensors is wired directly into the RPi.

I'm not sure if this has happened after running the code for the sensors
but I'm now unable to access the i2c busses:

cat /dev/i2c*
cat: /dev/i2c-0: Input/output error
cat: /dev/i2c-1: Input/output error

I note from the code that we're now using gpio17 instead of the i2c busses
which would account for that error I guess?

Few more coding issues but feel like we could do with some confirmation
that the hardware's correct before moving on?

Cheers,

Julian


On 29 April 2013 16:38, Martin Peach  wrote:

> Here's a patch to display data from two D6T sensors on the same I2C bus.
> The clock line is switched using a 4051 analog multiplexer. The control
> line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are
> at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1
> of the 4051 (I2C clock connects to X). Because the code accesses the GPIO
> file system it needs to be run as root. I have two different sensors so the
> code reads two different packet lengths. Just a proof of concept, there
> could be up to 8 identical sensors on the same bus with this setup.
>
> Martin
>
>
> On 2013-04-25 20:04, Julian Brooks wrote:
>
>> Just spotted this:
>> https://github.com/kadamski/i2c-gpio-param
>> Could be useful
>>
>>
>> On 25 April 2013 15:54, Martin Peach > > wrote:
>>
>> On 2013-04-25 10:37, Julian Brooks wrote:
>>
>> 'Nother 2 dumb questions:
>> What's the difference between the ones that have
>> spider/centipede type
>> legs and the straight ones (which would be best to get).
>>
>>
>> The PDIP package is what you want, not the SOIC. The only difference
>> is size. DIP packages are human-friendly, surface mount is for robots.
>>
>>
>> And also are you attaching the MC14051 to any type of
>> board/adaptor or
>> just soldering straight on to the pins?
>>
>>
>> I have it in a breadboard right now, to make it more permanent I
>> would solder a socket to a prototyping board then (after verifying
>> the connections) plug the chip into the socket. Soldering to the
>> pins makes it difficult to replace the IC, and risks damaging it
>> with the heat if you're not good at soldering quickly and to the
>> point. A CD4051 would also work, it's basically the same circuit.
>>
>> Martin
>>
>>
>>
>>
>
<>___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PDuino/Firmata - arduino object - PWM servo problem

[Maciej Sledziecki]

Solved the problem - has nothing to do with the PD object but only with the 
behaviour of the Arduino servo library:

"On boards other than the Mega, use of the library disables analogWrite() (PWM) 
functionality on pins 9 and 10, whether or not there is a Servo on those pins."
http://arduino.cc/en/Reference/Servo

Best,
Maciej

Am 30.04.2013 um 21:09 schrieb Maciej Sledziecki:

> Hello,
> 
> I´m running StandardFirmata 2.3. on Arduino Uno with PD extended 0.43.4 on 
> MacBookPro / MacOSX 10.6.8.
> 
> What I´m trying to do, is to drive two pins (9 & 10) in "pwm" mode and at 
> least two others (5 & 6) in "servo" mode.
> The pwm works fine - but only until I set one of the other pins to servo -
> then the diode that should be dimmed by pwm is either ON when receiving 
> "analog 1" or OFF when receiving any other value.
> 
> The only way to get back to pwm again, is to close the arduino comport an 
> reopen it again.
> 
> Is there a way to avoid this and to drive different pins in different modes 
> at the same time?
> 
> Thanks and best,
> 
> Maciej
> 
> 
> 
> 
> 
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list