[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SIGMusic] Discussion: Upcoming year



Looking at the SVN at http://svn.origo.ethz.ch/wsvn/linuxtuio/?op=log&isdir=1&; there hasn't been an update in a few months. I didn't check to see how far along the code is, but there still might be some useful code to steal.

On Tue, 10 Aug 2010 16:06:13 -0500, RJ Marsan <rjmarsan@xxxxxxxxx> wrote:

while we're at it:
http://linuxtuio.origo.ethz.ch/
No word on any progress in that.

Also, I have a pre-rooted android phone to test on as well.  As for
performance: no, the kernel module doesn't do the listening.  You have a
userspace tool that passes messages to /dev/uinput. or at least that's how
it appeared.

On Tue, Aug 10, 2010 at 2:03 PM, Misha Slavin <slavin3@xxxxxxxxxxxx> wrote:

I have an android phone that we could test stuff on. There's a lot to
discuss/research wrt kernel modules, I haven't really done any work with
them in the past but it seems straightforward enough for most things. I'm wondering if it will be unfeasible for performance reasons to have a kernel module listening on a socket for some remote input but that bridge should be
crossed later



On Tue, Aug 10, 2010 at 3:59 PM, RJ Marsan <rjmarsan@xxxxxxxxx> wrote:

http://www.math.bme.hu/~morap/RemoteInput/<http://www.math.bme.hu/%7Emorap/RemoteInput/>
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>wrote:

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> wrote:

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>wrote:

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>wrote:

!@#$ 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).

On Tue, Aug 10, 2010 at 3:16 PM, Allen Jacob McGinty <
mcginty@xxxxxxxx> wrote:

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.

Jake

On Tue, Aug 10, 2010 at 2:16 PM, RJ Marsan <rjmarsan@xxxxxxxxx>wrote:

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.

Future Projects:
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
SIGMusic-l@xxxxxxxxxxxx
https://www-s.acm.uiuc.edu/cgi-bin/mailman/listinfo/sigmusic-l



_______________________________________________
SIGMusic-l mailing list
SIGMusic-l@xxxxxxxxxxxx
https://www-s.acm.uiuc.edu/cgi-bin/mailman/listinfo/sigmusic-l