[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SIGMusic] Discussion: Upcoming year
- To: Misha Slavin <slavin3@xxxxxxxxxxxx>
- Subject: Re: [SIGMusic] Discussion: Upcoming year
- From: RJ Marsan <rjmarsan@xxxxxxxxx>
- Date: Tue, 10 Aug 2010 13:59:49 -0700
- Cc: sigmusic-l <sigmusic-l@xxxxxxxxxxxx>
Looks like a start? Its just keyboard input, but still remote, into the raw input processing line.
On Tue, Aug 10, 2010 at 1:54 PM, Misha Slavin <slavin3@xxxxxxxxxxxx>
I'd be interested. It is a somewhat difficult problem but if we're careful in planning we could create a kernel module that listens for TUIO signals and processes it all as multi-touch input (it's worth investigating how Android handles this at the kernel level in order to see what the 'standard' way of writing an input driver for android is)
On Tue, Aug 10, 2010 at 3:49 PM, RJ Marsan <rjmarsan@xxxxxxxxx>
The stock android emulator is pitiful in terms of performance. Intel's Android for x86 will be a huge thing for us. It'll also be open source. We'd still have to run it in a vm, but it'd run so much smoother.
The tuio driver is still a starter-worthy project, in my opinion. If we're careful we can write it in arch-independent C (if that's possible?)
On Tue, Aug 10, 2010 at 1:37 PM, Allen Jacob McGinty <mcginty@xxxxxxxx>
I never said we had to run it natively. As far as I know, vmware doesn't even support emulating an ARM processor, and even if it did, it would be ridiculous to emulate that instead of doing x86, so we'd have to do Android x86 regardless. We looked a bit into the TUIO driver, and Android has an increasing amount of built-in support for 3rd part input drivers.
Because of all that, I don't see why it wouldn't be prudent to start checking out Android x86.
On Tue, Aug 10, 2010 at 3:33 PM, Misha Slavin <slavin3@xxxxxxxxxxxx>
!@#$ AGH REPLY ALL
Android x86 is a non-starter since we'd have to rewrite the whole stack
of image combining, processing, filtering and finally translation into
cursors. The more realistic way to run android on Tacchi is within a VM
where we can have CCV send TUIO signals to vmnet (which would involve
writing a TUIO input driver for android's gui) or to have qemu process
multitouch natively (requires MPX, development on QEMU).
This humble dude's opinions:
1) Check out http://www.android-x86.org/
, where they have the x86 port of 2.2 (froyo) in development. I'm not sure if that's the same release that Intel will be chugging out for the upcoming tablets, but it still runs on a lot of hardware, and can be developed on. As RJ mentioned to me, it would be a GREAT project to make a new frontend to Android that focuses on multi-user friendliness. A ton can be done with this. And it will get popular quickly.
2) I proposed a DJ application. The problem is it'd be a lot of work, since I don't know of any OSS audio libraries that can do the skipping and time control that Traktor can do. I want to make an interface to Traktor, but that severely limits the re-usability of the code for anything else. Also, it's one more non-free software we'd rely on, which is always kind of poopy for the philosophy we have with Tacchi. We could also just move forward on the huge reactable-like application and its redesign for the new Tacchi.
Hey guys, Hope you all had an awesome summer.
I'm starting a discussion right now about next year, and the future projects of Sigmusic, and Tacchi.
1) Android on Tacchi
2) Music App for Tacchi
Those are two big and bold statements Feel free to add more. I've brought them up with several people already, and I know there's opinions on them, so speak up. I'm really hoping to get something awesome going this year.
SIGMusic-l mailing list