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 ([e-mail]):

> 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 - [e-mail]             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)