Re: Does this specific sound library exist?

	Subject: Re: Does this specific sound library exist?
	Date: gio 28 feb 13 05:25:40 +0900

Quoting Dirk Vogel ([e-mail]):

> So you're telling me the 'big work' that would be involved in my project
> and that would come from two directions (inclusion of custom UI elements
> and a pitch shifting mechanism that could be incorporated in a simple
> way) has not yet been done. 

I could never say this, since I do not know exactly what you want to
do. What I say is that covering unix, windows, mac, android and iphone
translates to 'big work' for any application that would want to
interact with the user, and that would want to generate live sound (I
am rather certain your application would want both of these).

> I hoped the "solid common frame" to overcome these
> differences would be an IDE 

IDE = integrated *development* environment. It is a tool to help
developers along the development process. What you are searching for
is a widget toolkit. WxWidgets seemingly would cover all your target
platforms apart from Android. About WxWidgets, I have no comments
(never had anything to do with it).

> What would be important, however, would be to be able to use my program
> at least on iOS and Android, 

From what I know, you need two separate codebases for that. 

> What are the projects like Ruboto and RubyMine for, then?

RubyMine is an IDE. For your concern it is irrelevant. 

Ruboto is an effort to map *Android's* SDK to Ruby. A honourable
effort, but it just tries to map Android's SDK objects one to one. I
did a little work with it, but decided to drop it, mainly because it
is a layer above Jruby, which itself is a layer above Java. Too many
layers, for my taste. Since I had to get familiar with the messy
lifetime of android apps anyway, for my experimental work I found it
more straightforward to do the UI coding in Java, leaving as much as I
could to C. 

Ruboto does not go in the direction of developing a multiplatform
UI. The target of the developers is to offer the possibility to
develop Android apps under Ruby in a relatively straightforward way.

In Android, the UI is much intertwined with the handling of the
lifetime of the app. In typical Google fashion, Android is very nosy
about your app. This is very different even from X. I know nothing
about iOS, but it would be very complex to port, say, Gnome to
Android. You may want to skim this article to get an idea:

http://lwn.net/Articles/510465/

> As to the pitch shifting problem, you're describing two different
> strategies to solve it. To "feed the DAC" seems absurdly complicated
> after your explanation. So what I'd have to do is to create this
> "daemon" that processes my sound files (fortunately they're very short,
> so one can hope it won't take too much time even for the relatively weak
> ARM processors of today's smartphones) and stuffs them into a tmp folder
> before they're used. Very well, but right now you made me suspicious:
> how (that is to say, in which program language) am I to  create this
> daemon, how does it link to ANSI C, what kind of frame work (IDE /
> compilers / ?) must I add? Because I imagine that this kind of stuff is
> not part of the normal SDK of whichever programming language...

This is very much offtopic here. Let me say that, in one way or
another, you need to feed samples to the DAC in order to hear anything
from your loudspeaker. That's how numbers are translated to a voltage
that itself translates to the moving of a magnet inside your
loudspeaker. This is the vibration you perceive. Anything else remains
at the level of numbers. And this is where all operating systems
seriously differ.

Thus: in order to have a process that performs acceptably in the audio
part, you NEED to have a very well-performing end-stage. If you want
to generate a CD-quality audio output, you must be SURE that, 44100
times every second, at regular intervals, your end-stage will feed a
new sample to the DAC. Each OS has developed some form of providing
this. Unfortunately, each approach, for what I know, is different.

The actual best way to tackle your holy grail would require a lot of
thought. I, for one, would never accept this challenge even as a
paid-for job, because covering multiple platforms is not my piece of
cake. I mourn the fact that the only real Linux-based phone (the Nokia
N900) was killed in the cradle by Nokia management. I am looking into
Android because I want to understand how my chinaphone works, but what
I see I do not like. Android is crippled Linux.

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - [e-mail]             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)