The pepper pad is a linux-based wifi touchscreen tablet. Compared to newer sleek devices it may seem clunky, but the screen is a nice size for touch interactivity and the odd split qwerty keyboard offers convenient tactile control.
Pepper pad can run VNC remote desktop client, so it can be used as a wireless touchscreen interface to any software on any platform.
In my own projects I used the pad to wirelessly control GDAM - dj mixing from around the room (tactile keys mapped to transport, looping, and effects functions), sequencers and break resequencing that anyone could try.
For Share I used the pad as a touchscreen interface to open source DAW Ardour running on an OSX tower. Musicians plugged into our mixing system from stage boxes situated around the venue, and I could monitor levels and adjust settings from whereever they were.
Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts
Saturday, January 24, 2009
Friday, November 16, 2007
Keep periodic unix processes from messing up your gigs
Sometimes while performing or working on audio/video, my hard disk activity light goes crazy. Top shows updatedb, makewhatis, and similar tasks running. With a well-tuned low-latency/realtime kernel the audio process should continue without dropouts... and indeed with the current ccrma kernels audio is fairly stable. But media access from disk can be slowed down (at least until preemption is perfected), and there's no need to be trying your luck. Keep the system load more constant and predictable by temporarily
These periodic (hourly/daily/monthly) processes are controlled by crond (old-school) and anachrond (new-school). Before a gig, run the following two commands as root:
[root@localhost]~# service crond stop
[root@localhost]~# service anacron stop
They'll be running again after a restart, which should be fine. Or run the above commands with "start" in place of "stop".
BTW, "service --display-all" gives a handy rundown of available services and prints detailed stats for some.
These periodic (hourly/daily/monthly) processes are controlled by crond (old-school) and anachrond (new-school). Before a gig, run the following two commands as root:
[root@localhost]~# service crond stop
[root@localhost]~# service anacron stop
They'll be running again after a restart, which should be fine. Or run the above commands with "start" in place of "stop".
BTW, "service --display-all" gives a handy rundown of available services and prints detailed stats for some.
Labels:
linux
Wednesday, June 6, 2007
upgrading fedocra 4 ccrma to 6
followed the yum upgrade procedure found by google. my biggest mistake was not upgrading to kernel > .14 before installing the rpm which changed the system and repositories to 5... it is mentioned (bottom of FAQ) that earlier kernels are incompatible with base RPM's.
Screw that, use a core 6 install DVD. Upgrade went smoothly, except that it replaced grub.conf!
Installed fedora 6 ccrma base. Installing ccrma-apps failed because of file conflicts... some packages, notable ladspa plugins, changed their name from version 4, and yum doesn't know to remove them. Installed apps in small batches, manually removing rhfc4.ccrma packages that conflicted (wasn't brave enough to remove *.rhfc4)
eventually i was able to install planetccrma-apps without error
used rpm -qai | grep rhfc4 to find packages eligible for update... even things as core and jack hadn't been upgraded to fc6! jack was particularly exciting because the upgrade pulled in freebob (firewire audio) support
the trickiest bit was
Transaction Check Error: file /usr/lib/libsndfile.so.1 from install of libsndfile-1.0.17-1.fc6 conflicts with file from package libsndfile1-1.0.13-7.rhfc4.at
because the package name changed from libsnd1 to libsnd. rather than force it, i removed libsndfile1, which removed a total of 58 audio packages. i put the list in a file to make sure i didn't lose anything
yum install planetccrma-apps again, pulled in the new libsndfile and a total of 53 packages
yum-update failed with file conflicts on kernel-headers, I didn't want to deal with it so I installed the rest in batches of a few dozen, nearly everything installed without conflict
my ipw2200 card broke, dmesg showed error -2 when installing firmware. i installed ipw2200-firmware packages and it worked again after restart
installing ntfs-g3 gave me ntfs support
Screw that, use a core 6 install DVD. Upgrade went smoothly, except that it replaced grub.conf!
Installed fedora 6 ccrma base. Installing ccrma-apps failed because of file conflicts... some packages, notable ladspa plugins, changed their name from version 4, and yum doesn't know to remove them. Installed apps in small batches, manually removing rhfc4.ccrma packages that conflicted (wasn't brave enough to remove *.rhfc4)
eventually i was able to install planetccrma-apps without error
used rpm -qai | grep rhfc4 to find packages eligible for update... even things as core and jack hadn't been upgraded to fc6! jack was particularly exciting because the upgrade pulled in freebob (firewire audio) support
the trickiest bit was
Transaction Check Error: file /usr/lib/libsndfile.so.1 from install of libsndfile-1.0.17-1.fc6 conflicts with file from package libsndfile1-1.0.13-7.rhfc4.at
because the package name changed from libsnd1 to libsnd. rather than force it, i removed libsndfile1, which removed a total of 58 audio packages. i put the list in a file to make sure i didn't lose anything
yum install planetccrma-apps again, pulled in the new libsndfile and a total of 53 packages
yum-update failed with file conflicts on kernel-headers, I didn't want to deal with it so I installed the rest in batches of a few dozen, nearly everything installed without conflict
my ipw2200 card broke, dmesg showed error -2 when installing firmware. i installed ipw2200-firmware packages and it worked again after restart
installing ntfs-g3 gave me ntfs support
Labels:
linux
Tuesday, June 5, 2007
Cloning lvm partition and booting from it
Problem: when bit-for-bit cloning a partition with a LVM system root results in duplicate physical volume ID's, and it is not possible to select which partition to boot into.
g4l partition clone hda2 into hda3
boot, will complain of duplicate PV ID but should load one of hda2/3
use vgscan to figure out which partition is in use (my case hda2)
edit /etc/lvm/lvm.conf find filter section and change filter to the following (my case, reject hda3):
filter = [ "r/hda3/", "a/.*/" ]
that will get rid of the warnings post-boot. to gain control over which is used at boot time, have to modify initrd. google "modify initrd", when you have it extracted edit its etc/lvm/lvm.conf as above. when you repack the img, name it _ignorehda3. put it into /boot/ next to the original.
do the same for _ignorehda2
edit grub.conf, copy the default/preferred option and paste it twice. change initrd to _ignorehda3 and _ignorehda2, give them nice display names such as "Original on hda2" and"Clone on hda3" respectively.
It is actually possible to change the uuid of the physical volume of the backup using pvchange -u, so that you can mount the backup. It is unclear whether this impacts your ability to boot off the backup.
g4l partition clone hda2 into hda3
boot, will complain of duplicate PV ID but should load one of hda2/3
use vgscan to figure out which partition is in use (my case hda2)
edit /etc/lvm/lvm.conf find filter section and change filter to the following (my case, reject hda3):
filter = [ "r/hda3/", "a/.*/" ]
that will get rid of the warnings post-boot. to gain control over which is used at boot time, have to modify initrd. google "modify initrd", when you have it extracted edit its etc/lvm/lvm.conf as above. when you repack the img, name it _ignorehda3. put it into /boot/ next to the original.
do the same for _ignorehda2
edit grub.conf, copy the default/preferred option and paste it twice. change initrd to _ignorehda3 and _ignorehda2, give them nice display names such as "Original on hda2" and"Clone on hda3" respectively.
It is actually possible to change the uuid of the physical volume of the backup using pvchange -u, so that you can mount the backup. It is unclear whether this impacts your ability to boot off the backup.
Labels:
linux
Subscribe to:
Posts (Atom)