2011/3/2 Olivier Guilyardi <list@email-addr-hidden>:
> On 03/02/2011 02:27 PM, Paul Davis wrote:
>
>> On Wed, Mar 2, 2011 at 8:20 AM, Olivier Guilyardi <list@email-addr-hidden> wrote:
>
>>> With this method, notably used by game devs, there's one code base, with thin
>>> platform drivers.
>>
>> i should comment here: although this is the *theory* behind game
>> development, its very far from the reality. for a variety of reasons,
>> i've been exposed to some of the internals of a number of real world
>> games recently, and they are the biggest mish-mash of toolkits and
>> APIs that i've come across. although its not the rule, its not
>> uncommon to find windows games, for example, that use up to three
>> different APIs for delivering audio.
>>
>> its certainly a good theoretical target, but don't hold up game
>> development as an example of somewhere that actually follows this
>> practice uniformly.
>
> Okay, well, I'm not into game development. I just mentioned that because there
> are a few game devs who actually rely on that kind of portable toolkit on
> Android. But I have no clue of what's really involved in highly complex games.
>
> Now, this discussion is more about audio and music apps.
>
> What I meant is to have the portable code base expose:
> process(*input, *output)
>
> And now, yes of course, you need thin drivers which calls this function. And if
> you want to support 4 platforms, you may need a dozen of drivers, yeah, but it
> sounds ok to me, as long as all the logic resides in the portable code base.
>
> At least in my very case, this should allow me to perform audio I/O on any
> mobile and non-mobile platform I can think of.
>
>>> But this later problem could be solved with a simple audio-oriented UI toolkit,
>>> which would render using OpenGL. A such toolkit could actually be very
>>> lightweight. For instance you do not necessarily need to embed entire charsets.
>>> A couple of characters (digits, "dB", etc..) could be sufficient in many cases.
>>
>> i know its the reality that you're facing right now, but as a bit of
>> an old-timer, i have to say that a lot of this discussion reminds me
>> of the early days of windows on 16 bit processors when people went to
>> all kinds of crazy effort to pack stuff into a hardware-limited
>> situation. it doesn't help things right now, but i just want to remind
>> you (as an old-timer) that just about every one of the limits you're
>> trying hard to pay attention to will evaporate within the next 5 years
>> :)
>
> First 5 years is a real lot of time when it comes to computing. I think that
> it's very risky to predict what will happen. Maybe you're right about technical
> limits evaporating, or maybe that technical approaches will take entirely new
> directions.
>
> Also, if you are talking about the browser limits, well, browsers are getting
> more and more advanced, web UIs are used in a variety of cases, yes. But the
> more powerful the machines become, the more audio applications will need to be
> powerful as well. And there always will be a gap between native optimized code
> and high level interpreted stuff. At least in the foreseeable future.
>
> Also, my OpenGL idea, although merely brainstorming so far, is not only
> applicable right now. It could also allow to build innovative 3D audio UIs. You
> could even embed 2D plugins UIs into a 3D scene.
>
> My point about OpenGL wasn't only about optimization. It just appears to be very
> portable, and yes also suitable for high-performance UIs today. And it seems to
> me like it can only get better in the future.
Let's try to make everybody (un)happy:
http://blogs.sonyericsson.com/developerworld/2011/02/24/webgl-support-in-the-android-web-browser/
However, as I see it now, this is a possible list of GUI techonologies
that may be worth considering:
1. HTML/JS/CSS (web UIs)
2. OpenGL (advanced UIs)
3. GTK+ and Qt (almost all current LV2 desktop hosts use either)
4. EFL (might be sound on "very embedded" devices)
5. SDL (as portable as possible)
plus all of the combinations of the above.
How to decide what to do? Let's choose targets...
Just an idea.
Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Mar 2 20:15:01 2011
This archive was generated by hypermail 2.1.8 : Wed Mar 02 2011 - 20:15:01 EET