Istvan Varga wrote:
> typedef struct
> { int basenote ;
> int gain ;
> int sustain_mode ;
> int sustain_start, sustain_end ;
> int release_mode ;
> int release_start, reslease_end ;
> } SF_INSTRUMENT ;
By the way, this is still not quite right (apart from the fact
of being unimplemented), given that all values are limited to be
integers. Having at least the base frequency and gain (I assume
the latter would only make sense as a signed decibel value if it
is of type int) as floats would definitely be useful, but
fractional loop points could also be of some use.

jpff@... wrote:
> When I attempt to run 106.orc/sco from Chapter 1 of the book on CS5 it
> gives errors -- No legal base frequency and loscil sustain defers to
> non-looping source. The sound is quiet and very short. Has something
> broken loscil or is libsndfile failing to handle loop points?
There is still no usable support for loop points in libsndfile,
and as a result they do not work in GEN01/loscil either. As of
now, libsndfile-1.0.12 has the following structure that can be
read from files with the apparently undocumented SFC_GET_LOOP_INFO
command:
typedef struct
{
short time_sig_num ; /* any positive integer >0 */
short time_sig_den ; /* any positive power of 2 >0 */
int loop_mode ; /* see SF_LOOP enum */
int num_beats ; /* this is NOT the amount of quarter notes !!!*/
/* a full bar of 4/4 is 4 beats */
/* a full bar of 7/8 is 7 beats */
float bpm ; /* suggestion, as it can be calculated using other fields:*/
/* file's lenght, file's sampleRate and our time_sig_den*/
/* -> bpms are always the amount of _quarter notes_ per minute */
int root_key ; /* MIDI note, or -1 for None */
int future [6] ;
} SF_LOOP_INFO ;
Note that it has no information about loop points at all (which
alone makes it useless), and the base frequency is specified in
MIDI notes as an integer - this is very limited. Also, there is
no information about amplitude scale. I assume this structure is
for tracks of recorded music (hence the parameters like tempo and
time signature), rather than loscil-like instruments.
There is also this structure that could be used by the also
undocumented SFC_GET_INSTRUMENT and SFC_SET_INSTRUMENT commands,
and this is exactly what we need. The bad thing is that it is
completely unimplemented - there is apparently no code for it
in the sources at all, even though the structure definition and
command names were already there in version 1.0.11.
typedef struct
{ int basenote ;
int gain ;
int sustain_mode ;
int sustain_start, sustain_end ;
int release_mode ;
int release_start, reslease_end ;
} SF_INSTRUMENT ;
So, in short, loop points for GEN01 and loscil are still not
possible with libsndfile. It is quite possible, though, that
loscil has bugs that are not related to looping.

When I attempt to run 106.orc/sco from Chapter 1 of the book on CS5 it
gives errors -- No legal base frequency and loscil sustain defers to
non-looping source. The sound is quiet and very short. Has something
broken loscil or is libsndfile failing to handle loop points?
==John ffitch

jpff@... wrote:
> I am looking at what is needed in a distribution of a stand-alone
> Csound5. As far as I can see the libraries
> libasound.so.2
> libjack.so.0
> liblo.so.0
> libportaudio.so
> libresmgr.so.0.9.8
> librt.so.1
> libsndfile.so.1
> are used by opcodes and csound, so either they need to be included or
> we should check for their existence.
>
> I have not looked at the Loris stuff, and I expect there are other
> bits I have not included.
>
> My installer now includes code to add OPCODEDIR/OPCODEDIR64
> environment variables, and there are 4 versions (single/double;
> 32bit/64bit).
>
> Which other libraries are needed? (other than c c++ dl pthread)
I assume FLTK should be included too, particularly given that the
one included with distributions is not usable in most cases, and
maybe PortMidi/PortTime. Perhaps libstdc++.so could be added too,
as it may have compatibility problems (one of the reasons why I
do not want libcsound to depend on it), and possibly libgcc_s.so
although I think that should be OK.
asound, dl, and pthread should be available and may not need to be
included. librt.so.1 is part of glibc, so it probably should not be
added to the package, either. While libsndfile is not necessarily
installed on all systems, it is a fairly standard package and should
be available as part of the Linux distribution. I am not sure what
uses libresmgr.so, as no Csound files seem to depend on it on my machine.
I have committed a script that creates an installable (to /usr/local)
directory tree, including the Csound executable, plugin libraries,
static and dynamic libcsound, headers, and xmg files, all this with
both single and double precision floats. It also creates simple shell
scripts that launch Csound and utilities, with setting OPCODEDIR,
OPCODEDIR64, CSSTRNGS, and LD_LIBRARY_PATH. Last, but not least, the
created package includes an uninstall script.
It is not really finished, though, as the directory structure may still
need some changes, as CsoundVST, csoundapi~ for PD, and the new
TclCsound are not supported, but a test installation seemed to work.

are we using libfltk.1.1.a insteand libfltk.1.1.so?
Victor
At 07:26 17/10/2005, you wrote:
>I am looking at what is needed in a distribution of a stand-alone
>Csound5. As far as I can see the libraries
> libasound.so.2
> libjack.so.0
> liblo.so.0
> libportaudio.so
> libresmgr.so.0.9.8
> librt.so.1
> libsndfile.so.1
>are used by opcodes and csound, so either they need to be included or
>we should check for their existence.
>
>I have not looked at the Loris stuff, and I expect there are other
>bits I have not included.
>
>My installer now includes code to add OPCODEDIR/OPCODEDIR64
>environment variables, and there are 4 versions (single/double;
>32bit/64bit).
>
>Which other libraries are needed? (other than c c++ dl pthread)
>==John ffitch
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@...
>https://lists.sourceforge.net/lists/listinfo/csound-devel
Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

I am looking at what is needed in a distribution of a stand-alone
Csound5. As far as I can see the libraries
libasound.so.2
libjack.so.0
liblo.so.0
libportaudio.so
libresmgr.so.0.9.8
librt.so.1
libsndfile.so.1
are used by opcodes and csound, so either they need to be included or
we should check for their existence.
I have not looked at the Loris stuff, and I expect there are other
bits I have not included.
My installer now includes code to add OPCODEDIR/OPCODEDIR64
environment variables, and there are 4 versions (single/double;
32bit/64bit).
Which other libraries are needed? (other than c c++ dl pthread)
==John ffitch

I had the same problem on Linux. Did you commit your
fix? I'll try it tomorrow.
Victor
>
> Ignore previous message. The error was that the
> widgets.cpp was not compiled with the correct libraries,
> as this was wrong in SConstruct. I found where to give a
> proper error message rather than the "cannot load" one and
> then chased. My fix may not be optimal but it actually
> works.
>
> ==John ffitch
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content,
> downloads, discussions, and more.
> http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

>> //void *v_cntl_win = (void *)cntrl_win;
>> void *v_cntl_win = NULL;
>>
>> // can we call the add timeout function here and pass it a pointer
>> to our display window?
>> Fl::add_timeout(1.0, cb_timer, v_cntl_win );
>> //Fl::add_timeout(.001, cb_timer );
>
>
> The main problem is here: a NULL pointer is passed to cb_timer(), and then
> as the 'this' pointer to ControlWindow::update_display() later. Removing
> v_cntl_win and passing cntrl_win instead fixes the crash. I did run into
> a number of minor compile errors and warnings but those are not related
> to this issue.
Thanks again Istvan. I was struggling to get that callback timer
working, and I guess I lost track of what tests I'd completed.
As to the concept, what do you think of that? Having the fltk window
live in a seperate thread that redraws itself after checking on api
values once every while.
Iain

Ignore previous message. The error was that the widgets.cpp was not
compiled with the correct libraries, as this was wrong in SConstruct.
I found where to give a proper error message rather than the "cannot
load" one and then chased. My fix may not be optimal but it actually
works.
==John ffitch

This is a repeat message;
I have noticed of late that I am no longer getting graphs but just
ascii pictures. I have just noticed when attempting to run
examples/fl.csd that I get the error message
WARNING: could not open library './libwidgets.so'
and then it continues to fail
On the other hand the file does exist
-rwxr-xr-x 1 jpff users 989303 2005-10-13 11:29 ./libwidgets.so*
What is going on?
0dBFS level = 32768.0
Csound version 5.00.0 beta (double samples) Oct 13 2005
libsndfile-1.0.11
UnifiedCSD: examples/fl.csd
STARTING FILE
Creating options
Creating orchestra
Creating score
orchname: /tmp/fileCqrUv0.orc
scorename: /tmp/fileWwjsmt.sco
****OSC: liblo started****
rtaudio: ALSA module enabled
rtmidi: PortMIDI module enabled
orch compiler:
16 lines read
error: no legal opcode, line 6:
FLpanel "This Panel contains a Knob and shows its current value",400,300
error: no legal opcode, line 7:
ih1 FLvalue "This is current value of output of the Knob", 100,20,50,20
error: no legal opcode, line 8:
gk1,gih FLknob "Current value of this Knob is shown in a text field", 80,5000,
This is clearly a symptom of a major problem. The error message is
way too terse. i assume that there is a missing library in FLTK but
this whole area has changed so much that I cannot even start to find
where this happens. Please could whoever broke this please please fix
it!
==John ffitch

Iain Duncan wrote:
> I have a question though, it seems to me in main that there might be
> some oddness over the calling of parse error control, there are a couple
> of spots where I can't see it being called. Can you look over that part?
It should be called after csoundCompile(), and the last call of
csoundPerformKsmps() which returned non-zero. Note that you should
actually ignore the return value of csoundCleanup(): even though
it returns an int, its purpose is not entirely clear. It had to do
something with exiting or continuing after the end of performance
in the now removed Winsound, but it definitely does not report errors,
and unless you register an ExitGraph callback of which the return
value would be returned, csoundCleanup() always returns zero.
It is possible that the return type of csoundCleanup() will be
changed to void to avoid confusion. Anyway, you may want to call
csoundReset() instead that implies csoundCleanup(), and calling
the latter explicitly is rarely useful and sometimes even dangerous.
> Example 4 will have an fltk window thread and the extra api bus
> functions I figure. I think examples 1, 2, & 3 might be good for the
> article in the csound Journal if all agree.
It would be nice to have an example that includes use
of the bus interface.
> /* change the below to the correct location of csound.h ( gimpy on my system right now ) */
> #include "/csound5/H/csound.h"
> //#include "csound.h"
I think it may be preferable to just have "csound.h", and specify the
include path on the command line for the compiler. Of course, this is
a C file, so not all compilers may like the // comments.
> #include <unistd.h>
This example does not actually need unistd.h. While it does not
make a difference most of the time, it does slightly reduce portability.
> /* Wait on the csound thread until it is done, this keeps main open until csound is finished */
> if ( cs_result = (int) csoundJoinThread( cs_thread ) )
> { printf("\n\n HOST: ERROR IN CSOUNDCLEANUP, EXITING. \n\n");
> return( cs_result ); }
In this message CSOUNDCLEANUP should really be PERFORMANCE.
I forgot to change that in the previous example, so the old
message is left there as a source of confusion.
> /* it is time to exit now, but why do we do this? who uses cs_data.exit_now
> at this point? is the display thread reading exit now? */
> csoundWaitThreadLockNoTimeout( cs_data.mtx );
> cs_data.exit_now = 1;
> csoundNotifyThreadLock( cs_data.mtx );
Well, you can remove the lock/unlock if you want, it probably
does not make much of a difference in practice. However, exit_now
does have to be set, otherwise the display thread would not know
when it should exit, and attempting to join the thread would never
return.
> /* Istvan, where does the parse error code get called here? */
> return cs_result; /* return the converted error code */
It is not called here, but rather in the Csound thread.
> /* csound has finished performing, so clean up and destroy */
> if ( cs_result = csoundCleanup(csound) )
> { printf("\n\n HOST: ERROR IN CSOUNDCLEANUP, EXITING. \n\n");
> return( cs_result ); }
Now this is the place where cs_result should not be set to the return
value of csoundCleanup(), as not only does this function not report any
errors (see above), but you also overwrite the error code preserved from
the last call of csoundPerformKsmps() which should not be ignored on the
other hand.

David Akbari wrote:
> How very interesting. I was able to reproduce this idea on the mac os by
> creating a disk image file of samples (a filesystem in memory like you
> said, *.dmg, which contained linear PCM encoded samples (.aiff, .wav))
> and buffersizes (-bx -Bx) of both x=128 and x=1024.
When referring to smaller buffer size, I meant the buffer size for
the soundin or diskin2 opcode, which is 2048 and 4096 mono samples
by default, respectively. Reducing the buffer size does not improve
the overall CPU usage, but makes it more evenly distributed and
possibly more friendly to low latency real time usage. However, on
a machine with very fast memory, this may not actually make a
significant difference.
> Would the comparison have been more accurate if tablei was used instead?
> (In other words, which type of interpolation is diskin2 using ... linear?)
diskin2 can use several interpolation types, including linear, cubic,
and sinc (with anti-aliasing) with number of samples ranging from 8 to
1024, as well as no interpolation. The default is cubic interpolation.
> I think it may be useful to see how diskin2 performs without
> interpolation. Perhaps appending an o-arg to diskin2 which is a boolean
> (default=1) to whether or not to use interpolation ?
It already has the "window size" parameter that selects interpolation
type:
1: none
2: linear
4: cubic
8 to 1024: sinc
However, for simple, fast non-interpolated reading of sound files,
soundin is preferred, unless you need resampling or the "wrap" feature
of the diskin opcodes.
> In what ways is it now possible to use S-variables and
> diskin2/soundin(s) to achieve a variable loading mechanism? Is it legal
> to just use:
>
> Sfile = "filename"
> aOut diskin2 Sfile, 1, 0, 1
Yes. soundin, diskin, and diskin2 evaluate the file name at i-time only,
though, so if you change it at k-rate you may need to use reinit to
make the opcodes switch to the new file.
In general, you can use a string variable as input argument to any
opcode that would require a "quoted string" according to the manual,
just remember that some opcodes may not respond well to the string
being changed at k-rate and using reinit may be needed.
> Are there currently any GEN routines that deal with the
> storage/retrieval of S-vars? Is it problematic to use GEN23 for this
> purpose?
Not yet, but the idea sounds interesting. Do you mean loading and
storing characters of a string from/to a function table (that is,
"foo" would translate to the four table values 102, 111, 111, 0) ?
Of course, you already have strset that is basically a global table
(rather like ZAK) of string values which can be read and written
with strget and strset, and sound I/O opcodes can also access the
strset table by specifying a number index instead of a string name.

Iain Duncan wrote:
> tries to lock the mutex for the csound data, and as soon as it does,
> csound segfaults. I can't see how this is any different from the same
> thing I did with the console thread, which worked fine. In both cases
> they used a local pointer to my main csound data structure which
> includes a mutex, and they use this local pointer to lock the mutex
> before reading table data.
> ...
> ControlWindow *cntrl_win = new ControlWindow( 400,400, "Control Window", v_cs_data );
>
> //void *v_cntl_win = (void *)cntrl_win;
> void *v_cntl_win = NULL;
>
> // can we call the add timeout function here and pass it a pointer to our display window?
> Fl::add_timeout(1.0, cb_timer, v_cntl_win );
> //Fl::add_timeout(.001, cb_timer );
The main problem is here: a NULL pointer is passed to cb_timer(), and then
as the 'this' pointer to ControlWindow::update_display() later. Removing
v_cntl_win and passing cntrl_win instead fixes the crash. I did run into
a number of minor compile errors and warnings but those are not related
to this issue.

On Oct 15, 2005, at 8:37 AM, Istvan Varga wrote:
> On a machine with lots of memory and an OS that allows for creating a
> filesystem in memory, this may be worked around to some extent; for
> example, on Linux you may try copying the files to tmpfs and reading
> with soundin or diskin2 with a small buffer size.
How very interesting. I was able to reproduce this idea on the mac os
by creating a disk image file of samples (a filesystem in memory like
you said, *.dmg, which contained linear PCM encoded samples (.aiff,
.wav)) and buffersizes (-bx -Bx) of both x=128 and x=1024.
I noticed a marked decrease in CPU % (as reported by maccsound and
top). This technique is very interesting and I look forward to
experimenting with it and implementing it more. Thanks for sharing this
idea!
> (note that you compared table which does not interpolate
> audio with diskin that does),
Would the comparison have been more accurate if tablei was used
instead? (In other words, which type of interpolation is diskin2 using
... linear?)
I think it may be useful to see how diskin2 performs without
interpolation. Perhaps appending an o-arg to diskin2 which is a boolean
(default=1) to whether or not to use interpolation ?
> the more important problem is occasional
> high peaks in CPU usage at opening the file or filling the input
> buffer,
> potentially resulting in buffer underruns in real time audio output.
Typically, the table loading technique seems efficient when using
multiple files, loading in and out (possibly just re-writing one
table).
In what ways is it now possible to use S-variables and
diskin2/soundin(s) to achieve a variable loading mechanism? Is it legal
to just use:
Sfile = "filename"
aOut diskin2 Sfile, 1, 0, 1
It would be nice because then of course you could be using reinit, if,
then, goto, and other high level logical operations to manipulate
S-variables which are ultimately loaded into one diskin2/soundin...
Are there currently any GEN routines that deal with the
storage/retrieval of S-vars? Is it problematic to use GEN23 for this
purpose?
-David

I remember people talking about fltk and thread problems, wondering if
that is what I have hit.
I'm working on my 4th example, and I have a member function of an fltk
class that get called periodically by the fltk timer callback. It then
tries to lock the mutex for the csound data, and as soon as it does,
csound segfaults. I can't see how this is any different from the same
thing I did with the console thread, which worked fine. In both cases
they used a local pointer to my main csound data structure which
includes a mutex, and they use this local pointer to lock the mutex
before reading table data.
Any hints? Could it be a problem with the csound api thread functions?
If it would be useful as a test I can redo it with raw pthread functions
and see what happens then.
Thanks
Iain

Can anyone tell me whether the csound thread creation functions allow us
to schedule low and high priority threads in a cross platform manner?
If I want to make sure one thread can pre-empt another when both could
be waiting on a mutex, will I have to use pthreads directly or can that
be done somehow with only api functions and api mutexes?
It seems to me that if I can make sure that one thread will *always* win
a race for a mutex, I can solve my scheduling problems by having two api
csound trapping threads that repeatedly lock->process->unlock only one
write at a time where the csoundPerformKsmp() thread will always win if
it needs to do stuff.
Thanks
Iain

So he added that did he? I did ask.
==John ffitch
>>>>> "Istvan" == Istvan Varga <istvan_v@...> writes:
Istvan> Note that a newer version of liblo that has lo_server_thread_del_method()
Istvan> may be needed.

Hi all, here is a revised version of api example 3 for looking over.
Istvan, I kept in your error code handling, the csound data structure,
the csound api timer functions instead of sleep, and the csound thread
and mutex functions instead of pthreads. I took out the extra api
methods in order to put those in the next example. I'd like to keep each
subsequent example only a bit more complicated than the last, so I
figured this was a good amount as compared to example 2, which is quite
a bit simpler.
I have a question though, it seems to me in main that there might be
some oddness over the calling of parse error control, there are a couple
of spots where I can't see it being called. Can you look over that part?
Another bit I would like to include is your code to apply --sched to the
host, but I suppose that is linux only so not as high priority.
Example 4 will have an fltk window thread and the extra api bus
functions I figure. I think examples 1, 2, & 3 might be good for the
article in the csound Journal if all agree.
Thanks again for all the help everyone
Iain

>> You're right, I think. It is not easy to determine how much to do before
>> passing control back to the audio production code. Matt's system in
>> MacCsound is VERY different because the OS butts in every time it
>> needs more
>> audio and his audio callback directly calls csoundPerform*. This is not
>> possible with the Csound 5 API though, AFAIK.
>
>
> It should be possible, as long as the audio callback does not have
> special requirements like not calling malloc() or other system functions,
> or having a hard deadline on completing audio processing which if not met
> would result in a crash, etc. I already tried this using PortAudio on
> Linux, and it worked fine, but the Mac may be different.
> In any case, it is likely that a host with special real-time requirements
> would implement its own audio I/O with any necessary custom features like
> monitoring CPU usage or using a host specific thread locking mechanism,
> rather than using the rtaudio plugins included with Csound.
This sounds conceptually like what I was intending when I was going on
about interrupts. If you have time to show us how one could could have
the audio callback ask for csound to perform I would like to see it.
Thanks
Iain

Istvan Varga wrote on 10/15/05 8:04 AM:
> The filtering code was already added for all platforms, although it
> only makes a useful difference where multiple loading of the same
> file does not return the same handle.
Yes, I tried it last night, and it works well. Thanks!
> Well, if there is no dirent.h interface on the Mac then a separate
> full implementation of csoundLoadModules() is needed anyway, and there
> is already an #ifdef that wraps the entire function.
That is my plan as dirent.h does not return the information really needed to
open a library on OS 9. Should be no problem to implement what I need.
>> BTW, it would be desirable to me to be able to output platform-specific
>> error messages from the functions csoundOpenLibrary(), csoundCloseLibrary(),
>> and csoundGetLibrarySymbol(). Would it be possible to have these functions
>> take a CSOUND* pointer so that csoundMessage, etc. may be called?
>
> These functions are intended to be generic wrappers that can be used
> by the host application without being associated with an instance pointer,
> so returning error values rather than printing messages may be preferred.
This would probably be an OK solution.
> In the case of csoundOpenLibrary(),
> there may be multiple reasons for not being able to open a file (typically
> either because the file does not exist, or it is not a dynamic library), so
> it could be changed to return an integer error value and store the handle
> in a void** argument.
I wanted to print more descriptive errors on this one because of the variety
of reasons for failure as you mention. In some circumstances, it would be
possible for a Csound plugin to be found and for everything to be OK except
that some other library that the plugin depends on is not available. On
MacOS 9, it is possible to identify exactly which library failed to load and
report that to the user. (A good example of this scenario would be trying
to load the python opcodes without a python library in the system).
But, either way -- being able to return an error code or being able to print
a custom message would be OK with me. Doing nothing would make debugging
slightly more time-consuming for me (and possibly annoying to users), but if
no one else cares about these issues, then I can live with that option as
well.
> printing messages may still be undesired, particularly in the case of
> csoundGetLibrarySymbol(): you would always get a long stream of error
> messages, as many of the plugin interface functions are optional and
> often not defined.
You are correct, of course! I did consider that.
> In fact, on most non-Mac platforms there are no separate ways for getting
> the address of a code or data symbol in a shared library. On Windows there
Encountering a symbol of the wrong type is the only error I can see wanting
to report from csoundGetLibrarySymbol(). But, this _should_ never happen in
practice. Therefore, I will remove the type check from the OS 9 code so
that it works the same as the other platforms :)
>> ** The value returned from csoundOpenLibrary(), BTW, has to be a number on
>> OS 9, not a pointer to some opaque structure. Casting the connection ID to
>> (void*) does seem to work, but makes me feel a little bit "dirty."
>
> Well, if you think casting to void* is not reliable for some reason, then
> you can allocate a CFragConnectionID with malloc() and return the address
> of that, with calling free() in csoundCloseLibrary().
I considered this as well. I will check if the cast is safe, and if not I
will take the malloc approach.
> Of course, if the return type is changed to some integer, then the other
> plastforms would have the ugly casts, or maintain a database of loaded
> libraries to which an integer index is returned.
I wasn't suggesting changing it -- I was really just pointing out the
difference for informational purposes.
Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/

How is it expected to work ? I see code that would attempt to hold
the previous output value when the trigger is not on, but it is not
implemented correctly, so the opcode outputs zero instead. So, should
holding the previous output be fixed, or should the existing code that
outputs zero when not triggered be kept (in this case the non-functional
parts could be removed) ? The manual does not define the behavior of
the opcode in this respect at all.
Note that all other opcodes in pycall.c.auto are affected as well,
but those in pyx.c.auto are apparently not.