Hi all
I am finishing a linux jack csound client.
(Finally, after a year of thinkng about it :))

I have a working version running but I am cleaning it up, and I have the
following questions/remarks on the api.

It seems that csoundCompile resets the HostData in some way.
If I set the external midiread callback before csoundCompile, I just get a
nullpointer for the hostdate in my callback, but if I set it after
csoundCompile I get the right pointer.

The same probably goes for the midiopen callback, but since that is only
caled from csoundCompile I can't check.

csoundCompile also doesn't load the function-tables into memory etc.
So all that gets done during the first csoundPerformKsmps.
That doesn't seem like a good idea to me, since the Perform is done in a
realtime callback, and allocating memory, drawing graphics etc doesn't
belong there. What I will do is to call csoundPerformKsmps once and then
rewind before starting the audio callbacks from jack, but that is kind of
hackish.

It would be nice to have api functions to get the current tempo and time
warping so csound can function as a timebase master.

Finally, I am using csound 4.23. If all of this is being adressed in the
work on csound5, ignore.

happy new year

Gerard

> It seems that csoundCompile resets the HostData in some way.
> If I set the external midiread callback before csoundCompile, I just get a
> nullpointer for the hostdate in my callback, but if I set it after
> csoundCompile I get the right pointer.

there is code in oload.c that is supposed to prevent this:

if (!cglob.GetVersion) {
      memcpy(&cglob, &cglob_, sizeof(GLOBALS));
      cglob.GetVersion = csoundGetVersion;
    }
 /**
     * The next time, copy everything EXCEPT the function pointers.
     * This is tricky because of those blasted macros!
     * We do it by saving them and copying them back again...
     */
    else {
      GLOBALS tempGlobals = cglob;
      size_t front = (size_t)&tempGlobals;
      size_t back = (size_t)&tempGlobals.SetRtcloseCallback;
      size_t length = back - front;
      back += sizeof(tempGlobals.SetRtcloseCallback);
      cglob = cglob_;
      memcpy(&cglob, &tempGlobals, length);
    }




> csoundCompile also doesn't load the function-tables into memory etc.
> So all that gets done during the first csoundPerformKsmps.
> That doesn't seem like a good idea to me, since the Perform is done in a
> realtime callback, and allocating memory, drawing graphics etc doesn't
> belong there. What I will do is to call csoundPerformKsmps once and then

but functions can be allocated at any time during a performance.  if you
are concerned with memory & graphics etc during an audio callback, you
need to make a host that defers these things [at this point at least]



-m

"Matt J. Ingalls"  writes:

> > It seems that csoundCompile resets the HostData in some way.
> > If I set the external midiread callback before csoundCompile, I just get a
> > nullpointer for the hostdate in my callback, but if I set it after
> > csoundCompile I get the right pointer.
> 
> there is code in oload.c that is supposed to prevent this:

I too have noticed the code in oload does not prevent hostdata from
being zeroed when csoundReset is called.  I currently use an ugly hack
to get around the problem until csound5 comes.  Besides, I could see
nothing obviously wrong with the code.

John

> but functions can be allocated at any time during a performance.  if you
> are concerned with memory & graphics etc during an audio callback, you
> need to make a host that defers these things [at this point at least]
>

True. I can change it that the audio callback communicates with the csound
thread using lockfree fifo's. But then I loose sample sync with other
applications, unfortunately.
I can see how to defer the graphics using the api, but how do I deal with
the memory ?

What is strange is that when I tested, it actually took a number of
performKsmps to load all the function tables defined in the score, but
only one performBuffer. I am using "Trapped in Convert" as a test piece.

Gerard

> True. I can change it that the audio callback communicates with the csound
> thread using lockfree fifo's. But then I loose sample sync with other
> applications, unfortunately.
> I can see how to defer the graphics using the api, but how do I deal with
> the memory ?

for mac os9, im overriding all the alloc/free/etc with my own functions
- i can send you the code for that if you want. [it would probably be
easier to incorporate into malloc/mfree/etc...]  but for OSX, even though
i run csoundlib inside the audio callback thread, i dont use my memory
manager, as i noticed no performance improvement - the only other
benefit is the security against memory leaks, but it seems like less of an
issue these days [whoever is responsible for that THANK YOU]

=m