These opcodes were rather limited in scope from the start, and were
originally restricted to a couple of output formats.  I did increase the
number a little but they still have these problems.

I have modified fout and foutk to use libsndfile, with two raw formats
and one WAV/AIFF/IRCAM format.  I have not checked them yet but there
is at least some semblance of working code. 

fouti/foutir is fundamentally flawed.  It allows one to open a file
with a number, which has previously been opened without knowing the
number of channels or the audio format.  This just does not fit the
libsndfile idea, and is anyway dangerous.

I think I want to rebuild these opcodes in a major way.  If one uses
fouti then the file must have been opened as an audio file with type,
and we can check the format if necessary.  fiopen would have its
second argument changed in meaning.

Any thoughts?  This introduces incompatible changes

==John ffitch

Hi John,

I think if it was flawed in the first place, it would be worth cleaning
up now before csound5 is out versus later.  

Perhaps a good policy for csound5 would be to ask the main users list in
regards to changes that would introduce incompatibilities. 

Thanks very much for all your work!
steven

p.s. - I've finally gotten some free time after a very demanding project
at work; I will be editing the SConstruct file to get working as I am
bit by the same inability to use the current one in CVS due to the
datetime package.  I will check in a working version for python 2.2
tonight if Michael doesn't beat me to it.



On Mon, 2004-04-05 at 00:40, jpff@codemist.co.uk wrote:
> These opcodes were rather limited in scope from the start, and were
> originally restricted to a couple of output formats.  I did increase the
> number a little but they still have these problems.
> 
> I have modified fout and foutk to use libsndfile, with two raw formats
> and one WAV/AIFF/IRCAM format.  I have not checked them yet but there
> is at least some semblance of working code. 
> 
> fouti/foutir is fundamentally flawed.  It allows one to open a file
> with a number, which has previously been opened without knowing the
> number of channels or the audio format.  This just does not fit the
> libsndfile idea, and is anyway dangerous.
> 
> I think I want to rebuild these opcodes in a major way.  If one uses
> fouti then the file must have been opened as an audio file with type,
> and we can check the format if necessary.  fiopen would have its
> second argument changed in meaning.
> 
> Any thoughts?  This introduces incompatible changes
> 
> ==John ffitch
> 
> 

Hi All,

I checked in a new version of SConstruct that removes the Python 2.3
datetime function and replaces with a utility function I wrote that uses
the time module.  Michael: I formatted the today() function to return
y_m_d i.e. today would be "2004_04_05".  I'm not sure if that's what the
datetime.time.today() function returns, but if not, feel free to edit. 
This SConstruct file runs without a hitch on my Fedora system that has
python 2.2.3.

I also added a check for CsoundVST that if on linux to ignore building. 
What was going on was that only on cygwin and windows was the pyrun
target being defined and so when it got down further past the
platform-dependent checks and was doing a Depends() on pyrun it was
coming up undefined.  I figured that to block building on linux until
CsoundVST has platform-dependent checks for it as well would be fine. 
(Saves me typing when running SCons).

Thanks,
steven

Sorry, does not work for me

ImportError: No module named zipfile:
  File "SConstruct", line 24:
    import zipfile

No idea what version of python I have -- this is the only use I have ever 
made of it.

If I comment out the include of zipfile ....

TypeError: function requires at least one argument:
  File "SConstruct", line 187:
    zipfilename = "csoundvst-" + sys.platform + "-" + str(today()) + 
".zip"
  File "SConstruct", line 33:
    return time.strftime("%Y_%m_%d",time.localtime())

Perhaps yet again I need to upgrade -- any suggestions as to how?
==John

I discovers that scons uses /usr/bin/python explicitly, which is unhelpful 
when python 2.3.3 installs in /usr/local/bin

Seems that changing scons gives me zipfiles

==John

yes i agree!

i say slash and burn down to only
in/out [change to allow any number of channels]
  and
inch/outch [channels can be number or string name]

and then assigning of channels can be done separately so you can route
to/from a file, audio device, another instrument, another application,
etc..

then get rid of all the specific oct/hex/16/32 etc in/outs, fouts, and
zak.

and mirror same interface for krate

probably would need to keep inx/outx for user-def opcodes

please let me know how i can help with this and i will!
-m




On Mon, 5 Apr 2004, stevenyi wrote:

> Hi John,
>
> I think if it was flawed in the first place, it would be worth cleaning
> up now before csound5 is out versus later.
>
> Perhaps a good policy for csound5 would be to ask the main users list in
> regards to changes that would introduce incompatibilities.
>
> Thanks very much for all your work!
> steven
>
> p.s. - I've finally gotten some free time after a very demanding project
> at work; I will be editing the SConstruct file to get working as I am
> bit by the same inability to use the current one in CVS due to the
> datetime package.  I will check in a working version for python 2.2
> tonight if Michael doesn't beat me to it.
>
>
>
> On Mon, 2004-04-05 at 00:40, jpff@codemist.co.uk wrote:
> > These opcodes were rather limited in scope from the start, and were
> > originally restricted to a couple of output formats.  I did increase the
> > number a little but they still have these problems.
> >
> > I have modified fout and foutk to use libsndfile, with two raw formats
> > and one WAV/AIFF/IRCAM format.  I have not checked them yet but there
> > is at least some semblance of working code.
> >
> > fouti/foutir is fundamentally flawed.  It allows one to open a file
> > with a number, which has previously been opened without knowing the
> > number of channels or the audio format.  This just does not fit the
> > libsndfile idea, and is anyway dangerous.
> >
> > I think I want to rebuild these opcodes in a major way.  If one uses
> > fouti then the file must have been opened as an audio file with type,
> > and we can check the format if necessary.  fiopen would have its
> > second argument changed in meaning.
> >
> > Any thoughts?  This introduces incompatible changes
> >
> > ==John ffitch
> >
> >
>
>

On a related note, I would appreciate it if we could get rid of the
restriction that input sound files must have the same number of channels as
the orchestra.  I haven't been able to figure out a way to make a simple
instrument to take a mono file as input using the -i flag and create a
stereo output from it (with a dual delay effect, for example).

My apologies if this is already possible and I haven't looked hard enough.

In addition, having some way for instruments to choose how many channels to
output based on the nchnls variable would be cool.

Ex.
nchnls  = 1

instr 201
    asig    oscil   10000, 200, 1
    
    if (nchnls == 1) then
            out     asig
    elseif (nchnls == 2) then
            outs    asig, asig
    endif
endin

This currently causes an orchestra compilation error (make it a runtime
error instead?).  An alternative might be C-style conditional macros:

#if     (nchnls == 1)
            out     asig
#elif   (nchnls == 2)
            outs    asig, asig
#endif

Anthony Kozar
anthony.kozar@utoledo.edu


On 4/7/04 12:11 AM, Matt J. Ingalls etched in stone:

> i say slash and burn down to only
> in/out [change to allow any number of channels]
> and
> inch/outch [channels can be number or string name]
> 
> and then assigning of channels can be done separately so you can route
> to/from a file, audio device, another instrument, another application,
> etc..
> 
> then get rid of all the specific oct/hex/16/32 etc in/outs, fouts, and
> zak.
 

An alternative that would obviate the need for any conditional code, would be to 
have any excess output channels simply ignored, with a warning printed to the 
screen.

In the general case, this issue suggests implementing a bus mechanism 
SAOL-style; though I guess the zak system is already desgined to offer that sort 
of facility.

Richard Dobson

Anthony Kozar wrote:
> On a related note, I would appreciate it if we could get rid of the
> restriction that input sound files must have the same number of channels as
> the orchestra.  I haven't been able to figure out a way to make a simple
> instrument to take a mono file as input using the -i flag and create a
> stereo output from it (with a dual delay effect, for example).
> 
> My apologies if this is already possible and I haven't looked hard enough.
> 
> In addition, having some way for instruments to choose how many channels to
> output based on the nchnls variable would be cool.
....