official Cycling74 ipad app coming!

So kind of like a TC-11 interface for Max. It will be interesting to see if MIRA uses OSC or if it uses some kind of new custom auto-connect UI for iPad control of Max params. I can currently run PD patches natively on both Android and iOS with lippd so I am hoping for a lot from Cycling.

Hello,

I would like to know if Mira will be sold for Android too. Android exposes an interesting feature on tablets with capacitive touch screens, that is the touch area for each contact. On some tablets the resolution is poor, but on others (such as the Galaxy Pad 2), the resolution seems to be pretty good, so that's an interesting feature to think about. It can be tested with the Touch Radius app (http://bit.ly/120z56C).

On iPad the corresponding information is not exposed to developers. Duh.

Keep in mind, folks!
Android main development language/OS language = JAVA
vs.
iOS main dev languages/OS language: Obj-C, C, C++,
Max/Msp dev languages C, C++ (js, java, obj-c) (parens = "language wrapper", not full implementation)
Note any alignment/ lack thereof??

RE: Linux port: Which UI kit? Sure seems like a lotta work to re-write the widget/window code (several times?) for a non-standardized/constantly evolving UI kit...(gnome? which !? & how stable a code base!?)
Which Linux release to compile to? everyone loves to pull out APT and bring lib levels up to a software's release level, it's so very ... geeky?
So, I sincerely doubt any effort to port to (some unnamed) Linux Or Android, with it's HORRIBLE latency....
ok, nuff annoying well intentioned tech rebels..... :-).
cfb aka j2k

Hi Roald
apologies for the slight detour here, but way back when, I recall reading a paper (somewhere?) highlighting the use of touch contact area (in a resistive touchscreen) as a surrogate for force or pressure data. I remember that the concluding verdict was "unsatisfactory". Have you encountered any such reference to this mapping before.

Again apologies for the hijack.

Brendan

Yeah, I've seen that work somewhere too Brendon.
The verdict also seems correct .
Firstly, each user would have to be calibrated -Drastic difference in finger size.
Plus its all too easy to lay more than a fingertip on a screen while 'using'.
Watch a tabla player!
Never mind latency...

1. I don't think that the coding language used to develop an OS matters as much as that, Java being a mature platfom (Cycling '74 has also integrated Java in Max, remember ?).
2. Android might be bad for *audio* latency. but here we are talking about OSC or MIDI. It's hard to compare two programs with different features, but for instance in my own experience the OSCPad app under Android is much more responsive than the Lemur App under iOS.
3. I have experimented with both resistive and capacitive touch sensing and I agree that it's nearly impossible to get consistent pressure data with a resistive touchscreen (at least the from one I have). However what I got from a Magic Trackpad (using capacitive technology) was really consistent. The only drawback was the mapping scale, probably set for palm rejection. Hence for one finger the number of levels was a bit too short. With an Android tablet (Asus TF101) the results were similar (not many levels) but the Galaxy Pad shows different figures so I think it's worth investigating.

>I don't think that the coding language used to develop an OS matters as much as that, Java being a mature platfom (Cycling '74 has also >integrated Java in Max, remember ?).

Spoken like someone who does not code for a living, :).
They (one or two Cycling74 devs) have "wrapped" a few MaxAPI calls, just a few, in Java, so they can be called from Java.
I don't see any further Java dev there from Cycling74: just maintenance and support: all of that will always be burdened down with the
java native code gateway/wrapper: and it is not so fast.
The core of MaxMsp/Jitter is still all C.

RE: Android.

The problem is not necessarily Java, although native implementation of all of the core max/msp/jitter functions in Java, rather than C is definitely not trivial!

And, yeah, "it" (porting Mira) would "just" be duplicating a ui widget set in a new language and OS,, porting all the event handling to new language/ API, , porting all the network code into a new language / OS.
As it is, they could probably leverage Macintosh UI code, network code , etc. on iOS: even the event system, which *has* to be slightly different appears to be fairly easy port to iOS from Mac code...and they are all a bunch of C/ObjC/C++ coders there at Cycling74: how convenient!
AFTER ALL
Perhaps It is just a question of economics.
they (cycling74) would have to hire/give hours to many more Java developers:
ones they don't currently have: or re-purpose a lotta C coders who
would be burdened by having to move to new environment/language/syntax.
And they can explore and receive benefit from this new technology (tablet) without said burden. now go figure.
Maybe it will happen. But dislike of large computer companies and economic desire (even driven by noble egalitarianism rather than base greed) will probably not sway the economic realities in the near future. In Madame Cunégonde's best of all possible worlds?...well, keep mentioning Android, and i will continue to try not find it all vaguely annoying and amusing.

AND! (sorry for continuing tangent I jst brushed on in last post) I am sure that as nice as it *would* be,
developing a nice tight core set of max/msp/jitter code without any ui dependancies, as a single linkable lib
("libpd" for max/msp/jitter) is a large enough task to discourage the effort without strong economic incentive...
and I kinda doubt the return on sales of said lib to devs would offset the effort, and it's corresponding inevitable re-writes of max core code;
at least right now.
ok, just my tuppence, really no harm intended...and I could very well be wrong, :)
cfbakaj2k

@Richard Baker: it seems you don't like Android and you have exposed some arguments against a version of Mira for this platform. However there are many arguments for too but I won't expose them because I suspect you'd dismiss them whatsoever. By the way if I am interested in such an application, it is as a end user, so I don't care if it's developed in Cobol, Logo, Fortran or even Whitespace and if its development is hard or easy, economical or costly for the company selling it. I am just interested in getting a simple answer to a simple question (Android version: yes/no), the reasons behind the answer are C74's own business, not mine neither yours.