From: "Carlo E. Prelz" Date: 2013-02-27T23:51:26+09:00 Subject: Re: Does this specific sound library exist? Subject: Re: Does this specific sound library exist? Date: mer 27 feb 13 09:27:32 +0900 Quoting Dirk Vogel (lists@ruby-forum.com): > 1. I may stress I'm a musician, not a programmer. As I worked with > Max/MSP all times, I know virtually nothing about IDEs, libraries, or > even different GUI guidelines for all these OS platforms. With Max/MSP > on my Mac, I'm able to develop little sound utilities as standalones, > and there's a Max runtime app that permits to run those standalones even > to those who don't own Max. So they cannot edit the standalone, but they > can use it, and the Max runtime app exists for Mac and Windows. (It's > like the Adobe Acrobat concept: most people use the Acrobat Reader to > read PDFs, but only a few have got Acrobat to build PDFs.) So that's my > background. Each platform has a different executable acrobat reader. The source code is not public, but I believe that the various codebases only share the library that interprets the PDF language (the language is public, by the way, so I can read and write PDF without using anything from Adobe). For the rest, Adobe will have some programmers who know how to write user interfaces for each platform. Remember that Adobe is a megacorp. I am familiar with PureData, rather than Max. When Miller wrote PureData, he used an existing UI: Tcl/TK. This has also been the choice of the early Ruby developers. But Tcl/TK is a bit lame, and Miller did a HUGE work to massage Tcl/TK to do what he wanted. I believe that the code in Max draws and manages its own graphic components directly (because they are very specific to the application). If true, at the moment of porting Max from Mac to Windows, the problem was just to provide the way to draw graphic primitives (i.e. coloured rectangles, lines, characters...). The big work had been done before. Basically, what you do not have is a solid common frame that would make such an effort as yours *easy*. And the reason for this is obvious: each platform has a UI, and nobody wants to discard it in favour of another one. This is why we do not all speak Esperanto, after all... > 2. Evidently the UI elements I built in my sound utilities look and work > the same under Mac and Windows, and it's impossible to respect the GUI > guidelines of both with the same UI as they differ, like everybody > knows. And even for what I'm planning to program this time I think it's > not that important that it feels like an application specifically built > for this or that OS. So I'm aware of the fact that many professional > programmers prefer to invest time in the development of specific UIs for > different platforms. I only hoped that an IDE like QT may effectively > take charge of the compilation of an UI you may have to develop only > once even if it runs on several OS. It is not the fact of them *looking* different. The fact is that the *model* that they are based on is completely different. Not only the graphics model, specifically the way the loop of events is handled. About QT I am not an expert because it is written in C++, and I also do not like the look of it from pure aesthetic reasons. Maybe it cuts your cake. > 3. So if I get you right, it's not reasonable to use Ruby if I've to get > a UI for Android. Even under Android, you can get ownership of the bitmap of the screen, so if you develop your UI the hard way, you can reach your holy grail, like Adobe and the people behind Max do. What I mean is that downloading the Android SDK and looking at some examples brings you quite quickly to the point where you can spit out your app with two buttons and an image. Operating any other way is not only much more difficult: it goes against the grain of what Google wants you to do, so they help you a lot less on your way... The UI is the bottleneck: a daemon in C is easy to write. > 4. Now to the pitch shifting method (or library or whatever). I already > know that libraries for a certain programming language may be written in > another language. I also know that pitch shifting is a time sensitive > operation and that a library that takes charge of it must be written in > assembler or C or something like that. But if I get the idea of > libraries right, they exist to incorporate this kind of function in a > programming language that may not be able to deliver it on its own, and > once you compile your program for a certain OS, it runs this function. > Now you tell me that there's an OS specific "underlying audio layer" to > deal with. What does that actually mean? Let's say for the argument's > sake that I'm to write my program in Java. Java runs on Android, but > also on Windows. Do you suggest I'd have to actually use two different > libraries for pitch shifting depending on the OS I'll compile my program > for? Even if Java runs on both? A library for the stretch/compress most probably exists in ANSI C - you can compile it wherever ANSI C is understood. So you can have a daemon that gets an audio file, processes it, and dumps it into another file. What is different is when you have to send your samples to the DAC. There, you must be sure that the audio chip is appropriately initialized and configured (and each chip is different), then you must be sure that the sample size, the speed, the number of channels, and a few other parameters are set the way you need them to be. Then you must start feeding to the DAC samples, at the right speed. Trying not to be disturbed by other tasks being run. All this is not trivial. And it has been solved in different ways by those who tackled it for the various OSes. > This comes as a surprise to me as in Max/MSP, pitch shifting exists as > an object you simply put in your data stream, and you get what you > want... From what I know, Max is very well optimized. Lots of work went into it. 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)