Hi everyone, I updated my cs_simple_2.c example to take some suggestions 
from y'all, please let me know if you consider this tutorial worthy and 
if not, how it should be changed.

Also, v1 of cs_simple_3.c is attached as well. In this one I add a 
pthreaded display thread that uses data taken from csound. A global data 
structure with a mutex is used to pass data out from csound on every 
kpass. It seems to be working just how I want on my linux machine, real 
time audio does not break up even with the cpu pinned to 98.6% by the 
mindless counting in the display thread. Would love to hear whether it 
works on other systems, as well as any comments on architecture and 
style so that it too can become tutorial worthy.

The next ones planned will be in rudimentary C++ and will add an fltk 
display window with data going in and out from csound and also portmidi 
input on the host end passed to csound as event calls. ( Probably in two 
different examples. ) Once the examples pass muster over here, I will 
post them on the main list and submit to csounds.com.

Thanks again for all the help,
Iain

I have attached slightly modified versions of the examples. The changes
are mainly fixes related to error handling, but I also made use of the
new bus interface in cs_simple_3. Of course, using tables is by no means
a bad method, but why not have examples of more different approaches ?
In addition, I replaced the empty loop that was used for busy waiting,
as it has two major disadvantages: the execution time depends on the speed
of the CPU, and even worse, the compiler may remove the loop completely
knowing that it does nothing.

Iain Duncan wrote:

> Hi everyone, I updated my cs_simple_2.c example to take some suggestions 
> from y'all, please let me know if you consider this tutorial worthy and 
> if not, how it should be changed.
> 
> Also, v1 of cs_simple_3.c is attached as well. In this one I add a 
> pthreaded display thread that uses data taken from csound. A global data 
> structure with a mutex is used to pass data out from csound on every 
> kpass. It seems to be working just how I want on my linux machine, real 
> time audio does not break up even with the cpu pinned to 98.6% by the 
> mindless counting in the display thread. Would love to hear whether it 
> works on other systems, as well as any comments on architecture and 
> style so that it too can become tutorial worthy.
> 
> The next ones planned will be in rudimentary C++ and will add an fltk 
> display window with data going in and out from csound and also portmidi 
> input on the host end passed to csound as event calls. ( Probably in two 
> different examples. ) Once the examples pass muster over here, I will 
> post them on the main list and submit to csounds.com.

Istvan Varga wrote:

> static int get_bus_channels( CSOUND *csound, MYFLT **p )
> {
> ...
> 	/* clear any remaining pointers to NULL */
> 	for (i = cnt; i < CS_DATA_BUS_LEN; i++)
> 		p[i] = NULL;

For completeness (and fixing a memory leak):

	if (names != NULL)
		free(names);
	if (types != NULL)
		free(types);

> 	/* return the number of control output channels actually found */
> 	return cnt;
> }


-------------------------------------------------------
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@lists.sourceforge.net

> I have attached slightly modified versions of the examples. The changes
> are mainly fixes related to error handling, but I also made use of the
> new bus interface in cs_simple_3. Of course, using tables is by no means
> a bad method, but why not have examples of more different approaches ?
> In addition, I replaced the empty loop that was used for busy waiting,
> as it has two major disadvantages: the execution time depends on the speed
> of the CPU, and even worse, the compiler may remove the loop completely
> knowing that it does nothing.

Thanks again for all the help. I agree that having more approaches to 
getting data in and out is a good thing, though I think I may move that 
stuff into example 4, again to just spread out the new info to the 
learner ( me, among others! ). The parser error function looks very 
useful, so I will leave that in as is. I was actually planning on doing 
pretty much a similar thing that you added with the mutex and the csound 
pointer and the command args all in one structure, and it looks like the 
csound thread functions are more appropriate for this example then the 
raw pthread stuff, so I think I will try to redo example three with your 
error handling, thread functions, and global csound structure, but 
saving the new bus code for the example 4 ( which will be example 3 with 
more examples of ways to use the api ).

However, I have some questions on the differences if you have time.

For what reason do we now call:
csoundInitialize( NULL, NULL, 0 );
at the beginning before spawining threads?

What do csoundWaitThreadLockNoTimeout( cs_data.mtx ); and 	 
csoundNotifyThreadLock( cs_data.mtx ); do exactly? I assume that the 
first is the same as a blocking wait on a pthread mutex? And for what 
purpose do we use them between joining the csound thread and the display 
thread?

Is there a no-wait version of the csound mutex function too? One where 
we try for the mutex, and then just continue on if we don't get it?

Thanks
Iain




-------------------------------------------------------
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@lists.sourceforge.net

> Hi All,
> 
> Just wanted to say these examples are really good thing IMO, and if
> they were accompanied with texts they could make a really nice manual
> or book I think.  Thanks for going through all of these examples!
> 
> steven

I will write accompanying articles later to make a tutorial series, but
I need to make sure I understand everything properly first ... ; )

And the goal for the whole series is to lead the reader up to making a 
properly constructed real time front end to their csound ensembles that 
includes midi i/o, keyboard i/o, fltk in and out, open GL out, and 
serial in/out to my pic chip hardware. It'll be a bit of a wait though.

Glad you like them!
Iain



-------------------------------------------------------
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@lists.sourceforge.net

> Hi All,
> 
> Just wanted to say these examples are really good thing IMO, and if
> they were accompanied with texts they could make a really nice manual
> or book I think.  Thanks for going through all of these examples!
> 
> steven

I will write accompanying articles later to make a tutorial series, but
I need to make sure I understand everything properly first ... ; )

And the goal for the whole series is to lead the reader up to making a 
properly constructed real time front end to their csound ensembles that 
includes midi i/o, keyboard i/o, fltk in and out, open GL out, and 
serial in/out to my pic chip hardware. It'll be a bit of a wait though.

Watch csound make sound, move displays, brew coffee, and now with 
dancing robots!

Glad you like them,
Iain



-------------------------------------------------------
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@lists.sourceforge.net

Iain Duncan wrote:

> For what reason do we now call:
> csoundInitialize( NULL, NULL, 0 );
> at the beginning before spawining threads?

It is there to make sure that the Csound library is initialized
before any threads attempt to use it. This function would otherwise
be implied by the first call of csoundCreate(), however, by that
time the display thread may already have used the timer functions
which depend on static data that is set up by csoundInitialize().

> What do csoundWaitThreadLockNoTimeout( cs_data.mtx ); and      
> csoundNotifyThreadLock( cs_data.mtx ); do exactly? I assume that the 
> first is the same as a blocking wait on a pthread mutex?

csoundWaitThreadLockNoTimeout() is really the same as
pthread_mutex_lock(), and csoundNotifyThreadLock() is
the same as pthread_mutex_unlock().
The function names may be confusing, though.

> And for what purpose do we use them between joining the csound
 > thread and the display thread?

They are used to protect access to the structure that is shared
between threads. Although, in this case it is only a write to
a single int value to notify the display thread that it should
exit, so using the mutex may not actually make much of a difference.

> Is there a no-wait version of the csound mutex function too? One where 
> we try for the mutex, and then just continue on if we don't get it?

There is
   PUBLIC int csoundWaitThreadLock(void *lock, size_t milliseconds);
that will return after waiting for the specified number of milliseconds.
The return value is zero if the mutex was successfully acquired
- in this case the function may return much earlier, and non-zero
if the timeout has elapsed but the mutex is still not unlocked by
another thread.
Calling csoundWaitThreadLock() with a zero timeout is basically
equivalent to pthread_mutex_trylock().
This function does have some disadvantages: it has more overhead
compared to calling the pthread functions directly (but not on
Win32 where it just calls WaitForSingleObject()), and on OS X you
can only have zero or infinite timeout.



-------------------------------------------------------
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@lists.sourceforge.net