Is there any reason why we couldn't allow a statement to appear 
following an if-then pair *without* a carriage return? I find myself 
wishing for code tightness that I could do:

if ( kfoo==kbar ) then k_dog=k_pizza
elseif ( kfoo>bar ) then k_dog=k_cheese endif

compacting 5 lines to 2. Thoughts?

Iain


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Csoudn is an assembler-level language and one statement per line is
the rule.  The "parser" works by looking for _the_ opcode.

Mind you the new parser could avoid this easily......

==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> Csoudn is an assembler-level language and one statement per line is
> the rule.  The "parser" works by looking for _the_ opcode.
> 
> Mind you the new parser could avoid this easily......

...if it was actually written. However, it seems there is a lot of
time for doing so, as the release date seems to be continuously
shifting away; I think we can forget about this year, and maybe
even the next summer. Perhaps the end of the next year, but some
projects (like a Mac installer or finishing the API) do not make
any progress, so even that is not sure.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What is needed to finish the API?
As for the Mac installer, once there is a decision on where things
should go, it can be created.

Victor

At 10:43 09/11/2005, you wrote:
>...if it was actually written. However, it seems there is a lot of
>time for doing so, as the release date seems to be continuously
>shifting away; I think we can forget about this year, and maybe
>even the next summer. Perhaps the end of the next year, but some
>projects (like a Mac installer or finishing the API) do not make
>any progress, so even that is not sure.

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> What is needed to finish the API?

Has "Query-Interface" been implemented? If not, at whatever point the API is 
declared to be finished, someone will ask for some new function to be added, and 
another, and another....  Compared to the size of the first draft of the API, 
way back when, the current one seems to reflect some form of Moore's law.

Richard Dobson






-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What is "Query-Interface" ?

At 11:37 09/11/2005, you wrote:
>Has "Query-Interface" been implemented? If not, at whatever point the API 
>is declared to be finished, someone will ask for some new function to be 
>added, and another, and another....  Compared to the size of the first 
>draft of the API, way back when, the current one seems to reflect some 
>form of Moore's law.
>
>Richard Dobson

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> What is "Query-Interface" ?
> 
> At 11:37 09/11/2005, you wrote:

I suggested it a while ago as a way to enable the API to be extensible; based 
more or less loosely on the much-loved Microsoft COM mechanism. Instead of 
perennially adding functions to the API sttructure, you have a structure with 
the function Query-Interface, which you use by asking if such and such a 
function is available.  Each such function has an ID ( a UUID), published in a 
header file, and each library module supplying one or more functions implements 
Query_interface, taking an ID as argument, and returns either NULL or a pointer 
to the requested function. The devil is no doubt in the details, and I am 
certainly not suggesting a full-blown COM system, but I can't think of any 
alternative that avoids the problem of either a continually evolving API, or a 
"frozen" API, given that there will always be something to add (and recalling 
all the howls when the code-freeze was announced...).

Richard Dobson





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:

> What is "Query-Interface" ?

I assume this function (Top/csound.c):

PUBLIC int csoundQueryInterface(const char *name, void **iface, int *version)
{
     if (strcmp(name, "CSOUND") != 0)
       return 1;
     *iface = csoundCreate(NULL);
     *version = csoundGetVersion();
     return 0;
}

In its current form it does not look very useful, but I think the
intended purpose is to return a table of function pointers and the
version of the selected interface. Of course, it now creates an
actual instance of Csound, and returns the package (and not API)
version, which may or may not be the intended behavior.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:
> Victor Lazzarini wrote:
> 
>> What is "Query-Interface" ?
> 
> 
> I assume this function (Top/csound.c):
> 
> PUBLIC int csoundQueryInterface(const char *name, void **iface, int 
> *version)
> {
>     if (strcmp(name, "CSOUND") != 0)
>       return 1;
>     *iface = csoundCreate(NULL);
>     *version = csoundGetVersion();
>     return 0;
> }
> 
> In its current form it does not look very useful, but I think the
> intended purpose is to return a table of function pointers and the
> version of the selected interface. Of course, it now creates an
> actual instance of Csound, and returns the package (and not API)
> version, which may or may not be the intended behavior.
> 

Well, not, it doesn't implement the intended bahaviour.

In very rough hand-wavy pseudo-code which is probably wrong in all sort of C 
details, I envisaged something like:

/* header file */
#define CSOUND_TABLEGET_ID 0xabcd10594631ffff

typedef   MYFLT (*csoundTableGetfn)(void *csound, int table, int index);

/* app file */
csoundTablegetfn *csoundTableGet = NULL;

csoundQueryinterface(csound,CSOUND_TABLEGET_ID, csoundTableGet);
/* or in COM style:
    csound->QueryInterface(CSOUND_TABLEGET_ID, csoundTableGet);
*/

if(csoundTableGet){
	/* get the table data, etc*/
}
else{
	printf("This version of Csound does not support 'csoundTableGet'\n":
	abort();
}


Of course, if something like this is not possible, we will just have to live 
with an "evolving" API which may require host apps to be rebuilt each time.

	
Richard Dobson




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have a MAC installer, not completely tested.
==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Nov 9, 2005, at 11:32 AM, jpff@cs.bath.ac.uk wrote:

> I have a MAC installer, not completely tested.
> ==John ffitch

Hi John,

I'd be more than happy to test this for you as I have also been working 
on Mac "installers" (using PackageMaker to copy prebuilt 32/64 bit 
binaries from canonical CVS to what appears to be the current 
"reasonable default locations" - identical to the directory structure 
present in the Istvan Varga 08-27-2005 build) and I would like to help 
in any way possible by testing!!

Is the MAC installer currently part of the Csound5 CVS module? Or is it 
part of a different module? If so what is the location; I feel that 
this issue is important and has not been addressed thoroughly enough, 
thus far in Csound5 development.

I am interested to attempt to implement installers for both Mac OS 10 
and Mac OS 9 that ensure compatibility with added features.


-David



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I personally do not see a need for an installer right now on MacOS 9.  I am
planning to provide a disk image as I usually do of the exact directory
structure needed to run Csound and the utilities.  It should be possible to
just drag and drop the files anywhere and have them work.

The only exception to this (so far) would be the Python interface.  That
requires copying two files into the Python distribution at specific places.
Also, some people may wish to copy the Csound5 shared library and plugin
libraries to the Extensions folder so that they can be found by multiple
hosts, but I would guess that anyone needing to do this is up to the task of
copying the files themselves.  (Although it would be fairly easy to write
Applescripts to do either of these tasks as well).

Did you have any specific concerns in mind that may need an OS 9 installer?

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.com/


David Akbari wrote on 11/9/05 12:24 PM:

> I am interested to attempt to implement installers for both Mac OS 10
> and Mac OS 9 that ensure compatibility with added features.



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Nov 9, 2005, at 10:49 PM, Anthony Kozar wrote:

> I personally do not see a need for an installer right now on MacOS 9.

In what capacity is Csound5 currently available on Mac OS 9 ? I 
currently use the Csound Development Preview versions at 32 and 64 bit 
precision (based on the old Mills versions) quite regularly when I am 
using this OS.

Is it possible to compile canonical CVS sources into binaries that will 
run on OS9 ? Or is additional programming required for a GUI since OS9 
does not have any Unix implementation (ie. Terminal)

>   I am
> planning to provide a disk image as I usually do of the exact directory
> structure needed to run Csound and the utilities.  It should be 
> possible to
> just drag and drop the files anywhere and have them work.

So essentially (for Mac OS 10 now) a user could just compile the 
sources from CVS do "Make Image from Folder..." in Disk Utility (after 
compiling) and this would be the distribution ?

> The only exception to this (so far) would be the Python interface.  
> That
> requires copying two files into the Python distribution at specific 
> places.
> Also, some people may wish to copy the Csound5 shared library and 
> plugin
> libraries to the Extensions folder so that they can be found by 
> multiple
> hosts, but I would guess that anyone needing to do this is up to the 
> task of
> copying the files themselves.  (Although it would be fairly easy to 
> write
> Applescripts to do either of these tasks as well).

Is it worthwhile (or even legal) to provide a .pkg or .mpkg executable 
of all precompiled dependencies (ie. libsndfile, liblo, libFLTK, etc) 
that, at runtime would copy the dependencies to the directories you 
mention ?

> Did you have any specific concerns in mind that may need an OS 9 
> installer?

Specifically liblo. As I see it, the best use of legacy computers with 
Csound synthesis is to set up "nodes" or a network of co-processing 
Csound performances. The Darwin kernel is slow enough (with its darn 
shadows and beveled EVERYTHING) so that rules out the possibility of 
installing Mac OS 10 on these older computers, yet their CPU 
capabilities are still desirable for use in software synthesis, IMO.

How can we get these sorts of things (specifically with OSC) to be 
happening on Mac OS 9 in addition to the currently functional OS 10 
implementation (from canonical sources) ?



-David



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote on 11/10/05 7:12 PM:

> 
> On Nov 9, 2005, at 10:49 PM, Anthony Kozar wrote:
> 
>> I personally do not see a need for an installer right now on MacOS 9.
> 
> In what capacity is Csound5 currently available on Mac OS 9 ? I
> currently use the Csound Development Preview versions at 32 and 64 bit
> precision (based on the old Mills versions) quite regularly when I am
> using this OS.

I have an alpha build of Csound 5 for OS 9 available for download from this
address:

http://briefcase.yahoo.com/bc/akozar@sbcglobal.net/lst?.dir=/Csound&.order=&
.view=l&.src=bc&.done=http%3a//briefcase.yahoo.com/

Sorry that I did not contact you about its availability.  Since you have
been regularly using Cs5 on OS X, I assumed that you would not have much
interest in an OS 9 version anymore.

Currently, this build is just the Csound5 library, a basic "Perf 5"
front-end that requires typing a command-line, the Python wrapper library,
and a set of all of the opcode plugin libraries that I have been able to
compile so far.  I have been working a great deal this week on recoding the
Mills GUI to work with Csound 5.  I could probably post a copy of that as
well in the near future.

> Is it possible to compile canonical CVS sources into binaries that will
> run on OS9 ? Or is additional programming required for a GUI since OS9
> does not have any Unix implementation (ie. Terminal)

The shared library for Csound 5 compiles quite easily and nicely by itself
once you manage to get libsndfile to compile (that requires a few changes).
I have never compiled the simple command-line front-end in
frontends/csound/csound_main.c, but it would work with some minor changes.

It would be rather pointless though since I have rewritten Perf to use the
API and my Perf 5 provides native OS 9 graphs and real-time audio out using
pretty much the same code used in Csound 4 and written by Matt Ingalls and
the Mills Csound team.

All of my project files and the latest Mac GUI code are available of course
for the asking.  I am currently using CodeWarrior pro 8 to compile
everything for Csound 5.  Scons does not work on OS 9, so having access to
some version of CodeWarrior is probably necessary to recompile any of the OS
9 binaries.  I made an attempt once to build Csound 4 with Apple's MPW.  I
was thwarted by the use of some non-ANSI-C unix calls that were available
with CodeWarrior's C library, but not with MPW's.  Since much of that code
has now been rewritten or replaced, I think, another attempt to use MPW
might be more fruitful.  That would be great since CodeWarrior costs several
hundred dollars and OS 9 versions may no longer be available.


>> I am
>> planning to provide a disk image as I usually do of the exact directory
>> structure needed to run Csound and the utilities.  It should be
>> possible to
>> just drag and drop the files anywhere and have them work.
> 
> So essentially (for Mac OS 10 now) a user could just compile the
> sources from CVS do "Make Image from Folder..." in Disk Utility (after
> compiling) and this would be the distribution ?

No.  Everything I was talking about in my previous email applied only to OS
9.  OS X is a whole different beast, and you cannot just store your binaries
and libraries wherever you wish and have them behave well.  Individual files
cannot just be rearranged on OS 9 either without possibly breaking things,
but there is more flexibility than with OS X AFAIK to install the entire
distribution anywhere and have it run.

> Is it worthwhile (or even legal) to provide a .pkg or .mpkg executable
> of all precompiled dependencies (ie. libsndfile, liblo, libFLTK, etc)
> that, at runtime would copy the dependencies to the directories you
> mention ?

.pkg and .mpkg are an OS X-only packaging system.  There is an old
Apple-made Installer maker for OS 9 but I believe that using it requires
actually obtaining a paper license from Apple.  The other common options for
slick installers on OS 9 are all commercial apps as well, AFAIK.  (I would
be happy to learn otherwise though).

libsndfile does not need to be installed by the end user because I am
statically linking it to Csound5Lib.  FLTK has not supported OS 9 since
version 1.0.x and I have no desire to see if it is possible to compile the
FLTK opcodes with that version.  There are currently no other dependencies
for Csound on OS 9 unless you want to use the Python functionality.

But as I said, if there are only two or three files in the OS 9 distro of
Csound that HAVE to be installed in a specific place, and those files are
related to less-used features like the Python interface or developing new
opcodes, then I do not see much worth in developing a full-blown installer.
I know of less than half a dozen people using Csound on OS 9 for sure, and
AFAIK, I am the _only_ person interested in programming with the Csound API
on OS 9.

>> Did you have any specific concerns in mind that may need an OS 9
>> installer?
> 
> Specifically liblo. As I see it, the best use of legacy computers with
> Csound synthesis is to set up "nodes" or a network of co-processing
> Csound performances. The Darwin kernel is slow enough (with its darn
> shadows and beveled EVERYTHING) so that rules out the possibility of
> installing Mac OS 10 on these older computers, yet their CPU
> capabilities are still desirable for use in software synthesis, IMO.

Hmmm ... do you really want to do this?  I have been wondering to myself
whether it was worth the effort to try to make the OSC opcodes work on OS 9.
Building them apparently requires the pthreads library and also (I assume) a
Posix-like sockets implementation.  MacOS 9 has no native implementation of
either of these.  There is an open source solution called GUSI but I have
had difficulty using it thus far.  (GUSI is incidentally how Python
implements threads and sockets on OS 9.  But from what I have read, there
are some subtle problems that can occur from mixing GUSI-using code (Python
or OSC) with non-GUSI-using code (Csound)).

If you really desire it, I can make the effort to compile the OSC opcodes.
But I cannot promise that it will work.  Even if they compile, they may not
work very well.  It would definitely depend on what you consider a "legacy
computer".  Macs like mine (a Beige G3 266Mhz) are probably not fast enough
to support real-time audio while responding to MIDI and/or networking
information.

So ... while I agree with you that using legacy Macs for getting more Csound
processing power is a cool idea (I have a small army of them myself that I
would like to utilize), I have been leaning more towards using my extra
machines for non-real-time rendering.  Along these lines, I have been giving
serious thought to developing a "Remote Csound Server" for MacOS 9.

"Remote Csound" would be an AppleEvent-aware background app that could run
on any legacy PowerMac with FileSharing and Program Linking turned on.  It
would be possible to send AppleEvents from one Mac using the front end to
any other listening Mac on an AppleTalk network to start and stop the
server, and to send it Csound jobs to process.  It would maintain a queue of
jobs and it might even be possible to view or control the queue remotely.
While I was primarily thinking of using this for non-real-time Csound, I
suppose it could also be used to start remote real-time processes as well.

Much of the infrastructure to make this work already exists.  Perf (any
version) already knows how to receive Csound commands via AppleEvents.  If
you were to turn on Program Linking and change one bit in Perf via ResEdit,
you could already run Csound remotely via an AppleScript.  Implementing the
queue and creating a nice GUI for controlling all of it are what I am
thinking about adding.  (There may also be issues with where you can put
your Csound input and output files -- on the remote computer or the local
host?)
 

> How can we get these sorts of things (specifically with OSC) to be
> happening on Mac OS 9 in addition to the currently functional OS 10
> implementation (from canonical sources) ?

Well, OSC will take some work as I said.  Remote Csound would also take some
work.  It would be nice though to get some feedback and to know that there
will actually be people using these features on OS 9 before I put any time
into them.

Sorry for the long rambling reply.  You did push my ramble button didn't
you?  ;-)

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.com/



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Nov 11, 2005, at 2:05 AM, Anthony Kozar wrote:

> while I agree with you that using legacy Macs for getting more Csound
> processing power is a cool idea (I have a small army of them myself 
> that I
> would like to utilize), I have been leaning more towards using my extra
> machines for non-real-time rendering.  Along these lines, I have been 
> giving
> serious thought to developing a "Remote Csound Server" for MacOS 9.
>
> "Remote Csound" would be an AppleEvent-aware background app that could 
> run
> on any legacy PowerMac with FileSharing and Program Linking turned on. 
>  It
> would be possible to send AppleEvents from one Mac using the front end 
> to
> any other listening Mac on an AppleTalk network to start and stop the
> server, and to send it Csound jobs to process.  It would maintain a 
> queue of
> jobs and it might even be possible to view or control the queue 
> remotely.
> While I was primarily thinking of using this for non-real-time Csound, 
> I
> suppose it could also be used to start remote real-time processes as 
> well.

This definitely seems like a more elegant solution than reinventing the 
wheel with ports and sockets on Mac OS 9 just for the sake of OSC !

Also, along these lines what potential dependencies does this idea 
introduce in relation to the packaged .img for Mac OS 9 ? Will this 
necessitate another library to be added to the Extensions folder ?

... and is it advisable to mirror your Csound5 alpha distribution on 
cSounds.com for others to use/test (who do not regularly read this 
list, or view it in digest mode and mostly do not reply) for which Mac 
OS 9 is still a primary platform ? (I know several individuals who fit 
this description)



-David



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote on 11/11/05 10:44 AM:

> On Nov 11, 2005, at 2:05 AM, Anthony Kozar wrote:

>> Along these lines, I have been giving
>> serious thought to developing a "Remote Csound Server" for MacOS 9.

> This definitely seems like a more elegant solution than reinventing the
> wheel with ports and sockets on Mac OS 9 just for the sake of OSC !

Well, keep in mind that "Remote Csound" would not allow any real-time
communication with those remote versions of Csound (other than starting and
stopping them).  Midi-control might eventually be possible, but you may
still want OSC if you are planning to have the computers "collaborate" in
real-time.

> Also, along these lines what potential dependencies does this idea
> introduce in relation to the packaged .img for Mac OS 9 ? Will this
> necessitate another library to be added to the Extensions folder ?

No extra dependencies.  Some extra configuration would be required though.
AppleTalk must be turned on for all Macs on the network that will
participate, and access to the File Sharing control panel is necessary so
that Program Linking can be turned on for those computers that will act as
remote servers.  Although these configuration changes can be scripted, it
might just be best to do it manually.

> ... and is it advisable to mirror your Csound5 alpha distribution on
> cSounds.com for others to use/test (who do not regularly read this
> list, or view it in digest mode and mostly do not reply) for which Mac
> OS 9 is still a primary platform ? (I know several individuals who fit
> this description)

I did not publically announce the alpha distro because of the extremely poor
state that the Mac interface is in.  However, if there are other people that
you think would be interested in trying it, please pass along the info to
them or feel free to mirror the package.  A new alpha package with a much
better interface will hopefully be ready within the next two weeks.  I will
announce that one on the main mailing list.

Thanks, David for your feedback.

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.com/



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Nov 11, 2005, at 1:33 PM, Anthony Kozar wrote:

> David Akbari wrote on 11/11/05 10:44 AM:
>
>> On Nov 11, 2005, at 2:05 AM, Anthony Kozar wrote:
>
>>> Along these lines, I have been giving
>>> serious thought to developing a "Remote Csound Server" for MacOS 9.
>
>> This definitely seems like a more elegant solution than reinventing 
>> the
>> wheel with ports and sockets on Mac OS 9 just for the sake of OSC !
>
> Well, keep in mind that "Remote Csound" would not allow any real-time
> communication with those remote versions of Csound (other than 
> starting and
> stopping them).  Midi-control might eventually be possible, but you may
> still want OSC if you are planning to have the computers "collaborate" 
> in
> real-time.

What about using this in conjunction with something like FTP so that 
you can instantiate Csound processes on several machines and retrieve 
their output via a "host machine" that you would sit at. Simply using 
FTP could also allow for transfer of source Csound files from the host 
machine to any given client; facilitating collaboration of Csound over 
several machines. If such an idea is implemented, it is likely that I 
would make the effort to acquire more Macintosh G3 computers.

The question is, what other means of file transfer exists other than 
FTP ? Would Remote Csound be capable of sending/receiving TCP or UDP 
(as it's protocol) ?

>> Also, along these lines what potential dependencies does this idea
>> introduce in relation to the packaged .img for Mac OS 9 ? Will this
>> necessitate another library to be added to the Extensions folder ?
>
> No extra dependencies.  Some extra configuration would be required 
> though.
> AppleTalk must be turned on for all Macs on the network that will
> participate, and access to the File Sharing control panel is necessary 
> so
> that Program Linking can be turned on for those computers that will 
> act as
> remote servers.  Although these configuration changes can be scripted, 
> it
> might just be best to do it manually.

Would it be possible to alter these configurations (Program 
Linking;AppleTalk toggle) from a host machine (ie. with no human 
interface devices hooked up to the client machines) ? Is this similar 
to the AppleScript that is suggested ?


Most intrigued,


-David



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote on 11/11/05 3:24 PM:

>>> On Nov 11, 2005, at 2:05 AM, Anthony Kozar wrote:
>>>> Along these lines, I have been giving
>>>> serious thought to developing a "Remote Csound Server" for MacOS 9.

> What about using this in conjunction with something like FTP so that
> you can instantiate Csound processes on several machines and retrieve
> their output via a "host machine" that you would sit at. Simply using
> FTP could also allow for transfer of source Csound files from the host
> machine to any given client; facilitating collaboration of Csound over
> several machines. If such an idea is implemented, it is likely that I
> would make the effort to acquire more Macintosh G3 computers.
> 
> The question is, what other means of file transfer exists other than
> FTP ? Would Remote Csound be capable of sending/receiving TCP or UDP
> (as it's protocol) ?

Well, AppleTalk and OS 9 File Sharing are the most obvious solution.  If all
remote machines are running File Sharing, then you can just mount their hard
drives directly on your desktop and copy files back and forth as needed.  If
the remote machines mount your local hard drive, then it should even be
possible for Remote Csound to read the .csd directly off of your computer
and write the output sound file back onto your hard drive (although this
will make Csound run _much_ slower).

It occured to me after my last email that the local front end could even
automate the process of copying files to the remote machine before a Csound
job and then copy the result back after its done.  All of this can be done
with AppleEvents over an AppleTalk network.  AppleTalk normally uses its own
protocol, but under OS 9 it is also possible to have File Sharing and
Program Linking connections occur over TCP/IP (although this is a huge
security hole if you are also connected to an external network via TCP/IP).

> Would it be possible to alter these configurations (Program
> Linking;AppleTalk toggle) from a host machine (ie. with no human
> interface devices hooked up to the client machines) ? Is this similar
> to the AppleScript that is suggested ?

Any AppleScript command that can be issued to a local machine can also be
issued to a remote machine.  However, in this case, you run into a chicken
and egg problem.  While you could have a script on the remote machine that
turns on AppleTalk and Program Linking, and you could run this script with a
command from the local machine, AppleTalk and Program Linking must already
be turned on for this command to work!  :)

Basically, the best situation would be to configure the machines
permanently.  This should not be a problem unless you are using a school lab
where they will get upset about you changing the file sharing settings.
Once the remote machines are configured though, they could all be "headless"
(without keyboards, mice, or monitors).

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.com/



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net