Fwd: New Music Controllers Workshop at CCRMA July 11-15

Dear all,

I'd like to invite you to attend the New Music Controllers workshop this summer at Stanford University.
This year, we are introducing a new platform for prototyping DIY new media projects. It uses the Beagle
Board and Arduino!

Looking forward,
Edgar Berdahl

Begin forwarded message:
New Music Controllers
CCRMA Workshop at Stanford University
Instructors: Edgar Berdahl and Chris Carlson
July 11-July 15, 2011
9AM-noon, 1PM-5PM

To sign up, visit http://ccrma.stanford.edu/workshops/new-music-controllers-nmc-0

Description: In this workshop, you will learn how to construct novel musical instruments and sound art
objects using an open-source open-hardware platform, which leverages the power offered by Arduino
(http://arduino.cc/en/Main/ArduinoBoardNano) and open-source software. By the end of the week, you
will make an autonomous project that runs independently of the Internet and other computers, meaning
that it will stand the test of time. This workshop goes the extra mile by mentoring participants in
evaluating and further developing their own ideas with the help of the Verplank physical interaction
design (PID) framework. Participants learn the philosophy and utility underlying the eight
interrelated PID perspectives: idea, metaphor, model, display, error, scenario, task, and control.

Alongside physical interaction design, the workshop integrates programming, electronics, robotics,
audio, and interactive music. Hands-on applications using sensors and microprocessors in conjunction
with real-time DSP will be explored for making music. Specific technologies will include Arduino

Fwd: Stompbox Design Workshop at CCRMA July 18-22

Because Satellite CCRMA can compute floating point computations natively, Esteban Maestre and I are also
teaching an audio effects workshop with it.

Thanks and see you there!
- Edgar

Begin forwarded message:
Sign up at http://ccrma.stanford.edu/workshops/stompbox-design

_______________________________________________
PlanetCCRMA mailing list
PlanetCCRMA <at> ccrma.stanford.edu
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma

A workaround for the "DSSI GUIs not working" problem in Fedora

I have found that a workaround for the dreaded DSSI GUI issue in
Fedora is disabling IPv6 support in liblo. Orcan, what do you think
about making this the default and backporting to FC13? I posted a
message asking for clarification at the liblo list, but I guess it
will take some time to work out a proper solution.

Cheers,

Luis

--------

PS: for those brave enough to try this at home, here is a small howto for FC13:

* As root, install some packages useful for rebuilding RPMs:

yum install rpmdevtools rpm-build yum-utils

As regular user, create a proper $HOME/rpmbuild tree:

rpmdev-setuptree

* Download liblo source RPM:

yumdownloader --source liblo

* Install it (it will go to $HOME/rpmbuild):

rpm -i liblo-0.24-6.fc13.src.rpm

Re: A workaround for the "DSSI GUIs not working" problem in Fedora

On Tue, Apr 5, 2011 at 4:15 AM, Luis Garrido wrote:
> I have found that a workaround for the dreaded DSSI GUI issue in
> Fedora is disabling IPv6 support in liblo. Orcan, what do you think
> about making this the default and backporting to FC13? I posted a
> message asking for clarification at the liblo list, but I guess it
> will take some time to work out a proper solution.
>

Hmm, liblo has been dead for a while. Let me know if you get a
solution from that side.
I am a little reluctant to modify existing libraries and change their
features in stable branches of Fedora.

Is there really no use case to have liblo compiled with IPv6 support?

Orcan

Re: FC13 Pulseaudio/Jack Delta 1010

Niels Mayer wrote:
> See also http://www.remastersys.com/forums/index.php?topic=1208.0
> HowTO: Run 2 M-Audio 1010LT's on AV Linux
>
> Niels
> http://nielsmayer.com
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA <at> ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>
>    
Thank you for the info and links. When I am less busy with work I will 
have a go.

Thanks

Ken

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: A workaround for the "DSSI GUIs not working" problem in Fedora

Yup, it is a kludge, even if this is the policy other distros have
adopted. That's why I employed the word 'workaround' instead of
'solution'.

The other workaround I know of is disabling IPv6 altogether for the
whole system, which is probably not a problem for domestic computers
behind an ADSL router, but may be more and more problematic in
academic and business environments.

Then there's NetworkManager overwriting /etc/hosts. I read somewhere
that they are going to drop this default behaviour, making it
optional, perhaps that will help.

I haven't looked too deep into this, but something should be done
because people keep tripping on this and it is getting a bit old.
Let's see if the liblo people or some IPv6 guru can offer a real
solution that doesn't reduce any functionality.

Luis

Re: A workaround for the "DSSI GUIs not working" problem in Fedora

On Tue, Apr 5, 2011 at 4:02 PM, Luis Garrido
<luisgarrido <at> users.sourceforge.net> wrote:

> Then there's NetworkManager overwriting /etc/hosts. I read somewhere
> that they are going to drop this default behaviour, making it
> optional, perhaps that will help.

OK, it is rather new, but it seems this development is out already in testing.

https://bugzilla.redhat.com/show_bug.cgi?id=648725

You install this version with:

yum update --enablerepo=updates-testing NetworkManager

I can confirm that it doesn't add the hostname to the IPv6 loopback
line anymore. Maybe you still have to delete it, but NM won't put it
back. This does seem to be a fix for the condition that afflicted
liblo's behaviour [1].

IPv6 loopback line in /etc/hosts must be something like:

::1             localhost6.localdomain6 localhost6

Luis

[1] http://old.nabble.com/jack-dssi-host-td30398457.html

Re: A workaround for the "DSSI GUIs not working" problem in Fedora

On 04/05/2011 08:02 AM, Orcan Ogetbil wrote:
> On Tue, Apr 5, 2011 at 4:15 AM, Luis Garrido wrote:
>> I have found that a workaround for the dreaded DSSI GUI issue in
>> Fedora is disabling IPv6 support in liblo. Orcan, what do you think
>> about making this the default and backporting to FC13? I posted a
>> message asking for clarification at the liblo list, but I guess it
>> will take some time to work out a proper solution.
>>
> 
> Hmm, liblo has been dead for a while. Let me know if you get a
> solution from that side.
> I am a little reluctant to modify existing libraries and change their
> features in stable branches of Fedora.
> 
> Is there really no use case to have liblo compiled with IPv6 support?

Is there no workaround for an already installed system, short of
rebuilding RPMs and recompiling liblo.

I'd love to get a reasonably easy way to fix this stupid problem that
doesn't risk the entire installation, or involved downloading dozens of
other packages to meet dependency requirements of rebuilding and
repackaging RPM files.

--

-- 

Check out the website I've been cobbling together.  It will never be
done, but it's a start:
  http://lateralforce.no-ip.org

Re: [PlanetCCRMANews] RME9652 problems aggravated by kde update

On 04/06/2011 02:40 PM, Craig Bourne wrote:
> A few days ago, in the midst of testing to document the existing level
> of audio support on my system following an earlier report of problems, I
> applied the most recent set of KDE updates after which my system was silent.
>
> The only exception being that both the firefox and chrome the browser
> rendered audio as expected when browsing multimedia files.
>
> My first attempt at a repair (as I awaited advice from queries off this
> list) came as a result of noting that in recent posts it was now
> considered counterproductive to specify the hardware device to <<insert
> name of ALSA client application here>> and this set me to thinking about
> the information that I had been taught, over the past several years, to
> convey to JACK when invoking it (as in "-d hw 0:0").

Let's see:

Jack: definitely DO use hw:xxx for starting jack. Always.

ALSA applications that are not jack aware (which ones do you use??): 
well, it depends on what you want them to use. Using "default" as the 
device will pipe output through PA. Could be good or not depending on 
the application and your needs. If you specify the soundcard directly 
then it might not work as PA may be using it already (Jack has special 
code that asks PA for the card).

In short, always use Jack if possible.

BTW, the best way to tell jack which soundcard to use would be to use 
its name, for example in the laptop I'm typing this I can find the name 

Re: RME 9652 - ALSA - Pulseaudio problems

On 04/06/2011 03:18 PM, Craig Bourne wrote:
> Here are messages logged to /var/log/messages by pulseaudio:

By default PA can't use an RME card out of the box as it can't find a 
default mapping for all the available channels. There is a workaround 
that involves telling it explicitly. I'm attaching a file that I use for 
our RME Multiface II cards.

Note that you will need to adjust number of channels and name of the 
soundcard to match what you have...

-- Fernando

> Apr  6 16:49:59 speedy pulseaudio[2312]: module-alsa-card.c: Failed to find a working profile.
> Apr  6 16:49:59 speedy pulseaudio[2312]: module.c: Failed to load  module"module-alsa-card" 
(argument:"device_id="0"  name="pci-0000_02_00.0"  card_name="alsa_card.pci-0000_02_00.0" 
tsched=yes ignore_dB=no card_properties="module-udev-detect.discovered=1""): initialization failed.
>
> Apr  6 16:50:00 speedy pulseaudio[2312]: module-alsa-card.c: Failed to find a working profile.
> Apr  6 16:50:00 speedy pulseaudio[2312]: module.c: Failed to load  module"module-alsa-card" 
(argument:"device_id="0"  name="pci-0000_02_00.0"  card_name="alsa_card.pci-0000_02_00.0" 
tsched=yes ignore_dB=no card_properties="module-udev-detect.discovered=1""): initialization failed.
>
> Apr  6 16:50:00 speedy pulseaudio[2312]: module-alsa-card.c: Failed to find a working profile.
> Apr  6 16:50:00 speedy pulseaudio[2312]: module.c: Failed to load  module"module-alsa-card" 
(argument:"device_id="0"  name="pci-0000_02_00.0"  card_name="alsa_card.pci-0000_02_00.0" 
tsched=yes ignore_dB=no card_properties="module-udev-detect.discovered=1""): initialization failed.
>
> Apr  6 16:50:00 speedy pulseaudio[2312]: module-alsa-card.c: Failed to find a working profile.
> Apr  6 16:50:00 speedy pulseaudio[2312]: module.c: Failed to load  module"module-alsa-card"