simon.urbanek at r-project.org
Thu Aug 28 19:41:42 CEST 2008
On Aug 28, 2008, at 3:04 AM, Hans-Jörg Bibiko wrote:
> On 27.08.2008, at 17:21, Hans-Jörg Bibiko wrote:
>> On 27.08.2008, at 17:06, Simon Urbanek wrote:
>>> To be precise to play an audio file all you do is
>>> [[[NSSound initWithContentsOfFile:fileName byReference:YES]
>>> autorelease] play];
>>> Thats' all :)
>> Ah, you mean that the function play(A_SOUND_FILE) should be part of
>> R's core code which implements it for a given platform.
>> This of course would be the best way.
> I thought about it a bit. For Mac it would be trivial, but for
> Windows and Linux I do not know. They have to support many sound
> card drivers. For Linux you have different window servers, and
Fortunately all OSes have API that is independent of the sound card
and it has nothing to do with the window servers. There is one API on
Windows and one on Macs. For unix it's not as easy since there is no
real standard across unices, but supporting OSS and/or ALSA should
cover the need of the majority of users.
> The next point once you have such a built-in function like
> playSoundFile(f) how to control it, i.e how to stop it for instance;
> esp. for the case that you're playing more than one sound file at a
> time (which works a Mac with play very well).
That is something you cannot easily do with command line tools but is
trivial in the native implementation. In addition, you're not
restricted to files, you could play off R functions or vectors...
> To use the approach to open a sound file by the default application
> is in some sense better.
I would dispute "better" here - if anything it's the easiest, because
you're offloading the task to another application...
> On Mac it's easy, just type 'open FILE', for Windows this works only
> in some cases. One could use 'start FILE' but 'start' is not an
> executable it's a DOS command thus one could write a BAT file
> open.BAT à la 'start %1'. The tricky point is Linux in that respect
> I believe. I do not know any command which can do this. The Linux
> shell command 'play' is not part of any distribution.
> This leads to a next problem. If there would be a general solution
> to play a sound file using the default app OK but if the user can
> set up the player to 'mplayer32.exe', or 'play' etc. how to
> distinguish between a shell command, which could run in the
> background (how to control it?), and a app based program like
> 'Windows Media Player' or 'QuickTime' etc.?
> The only idea I have for now is to use a scripting language to write
> a primitive audio player, and the only language which is installed
> by default on all these platforms is Java. It shouldn't be that
> problem to write such a JFrame jar.
I suspect you're talking about something entirely different - JFrame
won't give you any sound playback ;). But, yes, using Java would be
one option except that Java is quite a heavy requirement for such
More information about the R-SIG-Mac