From: "Carlo E. Prelz" Date: 2013-02-28T19:00:00+09:00 Subject: 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 (lists@ruby-forum.com): > 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 - fluido@fluido.as che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)