hey all,

if you get the following error using the wii opcodes:

[INFO] Found 1 bluetooth device(s).
[INFO] Found wiimote (00:1F:32:F1:8D:0C) [id 1].
connect() output sock: Invalid argument
Failed to connect to any wiimote.

Michael LaForest suggests modifing the source of libwiiuse in the 
following way:

memset(&addr, 0, sizeof (addr)); //is missing in the line 174 of io_nix.c

it worked for me.

kelly hirai


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

It seems like Apple has developed a rather interesting parallelization
toolkit called Grand Central Dispatch[1]. Furthermore, it has been
released as open source[2]. Unfortunately, it has been released under
the Apache license which is not compatible with the GPL, and it requires
blocks, a compiler feature which is not in gcc yet. It may evolve
interestingly, or an alternative GPL-compatible implementation may
appear. 


[1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
[2]
http://arstechnica.com/open-source/news/2009/09/apple-opens-gcd-challenges-impede-adoption-on-linux.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss

-- 
Saludos,
Felipe Sateler

What is the advantage of Grand Central Dispatch over OpenMP, which is
implemented in all compilers used to build Csound?

Regards,
Mike

On 9/14/09, Felipe Sateler  wrote:
> It seems like Apple has developed a rather interesting parallelization
> toolkit called Grand Central Dispatch[1]. Furthermore, it has been
> released as open source[2]. Unfortunately, it has been released under
> the Apache license which is not compatible with the GPL, and it requires
> blocks, a compiler feature which is not in gcc yet. It may evolve
> interestingly, or an alternative GPL-compatible implementation may
> appear.
>
>
> [1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
> [2]
> http://arstechnica.com/open-source/news/2009/09/apple-opens-gcd-challenges-impede-adoption-on-linux.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
>
> --
> Saludos,
> Felipe Sateler
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The main advantage is that csound just issues tasks to be done, it is
the OS which takes care of deciding how many threads should be spawned.
This way you forget about how managing the threads, but instead manage
tasks (which, BTW, can be queued up as a DAG). 

On Mon, 2009-09-14 at 14:23 -0400, Michael Gogins wrote:
> What is the advantage of Grand Central Dispatch over OpenMP, which is
> implemented in all compilers used to build Csound?
> 
> Regards,
> Mike
> 
> On 9/14/09, Felipe Sateler  wrote:
> > It seems like Apple has developed a rather interesting parallelization
> > toolkit called Grand Central Dispatch[1]. Furthermore, it has been
> > released as open source[2]. Unfortunately, it has been released under
> > the Apache license which is not compatible with the GPL, and it requires
> > blocks, a compiler feature which is not in gcc yet. It may evolve
> > interestingly, or an alternative GPL-compatible implementation may
> > appear.
> >
> >
> > [1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
> > [2]
> > http://arstechnica.com/open-source/news/2009/09/apple-opens-gcd-challenges-impede-adoption-on-linux.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
> >
> > --
> > Saludos,
> > Felipe Sateler
> >
> 
> 
-- 
Saludos,
Felipe Sateler

But OpenMP does the same thing. You declare a parallel block, OpenMP
implicitly creates a task and automatically figures out a good number
of threads to run the block in parallel tasks.

OpenMP can also nest parallel blocks inside parallel blocks.

Regards,
Mike

On 9/14/09, Felipe Sateler  wrote:
> The main advantage is that csound just issues tasks to be done, it is
> the OS which takes care of deciding how many threads should be spawned.
> This way you forget about how managing the threads, but instead manage
> tasks (which, BTW, can be queued up as a DAG).
>
> On Mon, 2009-09-14 at 14:23 -0400, Michael Gogins wrote:
>> What is the advantage of Grand Central Dispatch over OpenMP, which is
>> implemented in all compilers used to build Csound?
>>
>> Regards,
>> Mike
>>
>> On 9/14/09, Felipe Sateler  wrote:
>> > It seems like Apple has developed a rather interesting parallelization
>> > toolkit called Grand Central Dispatch[1]. Furthermore, it has been
>> > released as open source[2]. Unfortunately, it has been released under
>> > the Apache license which is not compatible with the GPL, and it requires
>> > blocks, a compiler feature which is not in gcc yet. It may evolve
>> > interestingly, or an alternative GPL-compatible implementation may
>> > appear.
>> >
>> >
>> > [1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
>> > [2]
>> > http://arstechnica.com/open-source/news/2009/09/apple-opens-gcd-challenges-impede-adoption-on-linux.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
>> >
>> > --
>> > Saludos,
>> > Felipe Sateler
>> >
>>
>>
> --
> Saludos,
> Felipe Sateler
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Felipe Sateler wrote:
> It seems like Apple has developed a rather interesting parallelization
> toolkit called Grand Central Dispatch[1]. Furthermore, it has been
> released as open source[2]. Unfortunately, it has been released under
> the Apache license which is not compatible with the GPL, and it requires
> blocks, a compiler feature which is not in gcc yet. It may evolve
> interestingly, or an alternative GPL-compatible implementation may
> appear. 
> 

Unfortunately it appears to be rather less exciting that hoped. Ditto 
OpenCL (at least, for real-time audio). This is from an Apple developer 
on the CoreAudio list:

"Ehm, you know that GCD is running at the main thread level? Which can 
be blocked by UI operations, etc. That doesn't seem like a wise choice 
for real-time processing. OpenCL also doesn't have a threading mode, so 
you tasks will be shared among all the others and your latency becomes 
unpredictable.
"

So whatever tasks it may be useful for, parallelizing Csound seems 
unlikely to be one one of them.

Richard Dobson



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I still think we should keep going with pthreads, possibly considering
OpenMP in the future. But as the FAUST guys showed, things are not
straighforward anyway (although I guess they were aiming at a too fine
level of granularity).

I have great hopes for the system John's been preparing.

Victor
----- Original Message ----- 
From: "Richard Dobson" 
To: "Developer discussions" 
Sent: Monday, September 14, 2009 7:57 PM
Subject: Re: [Cs-dev] Another parallel toolkit


> Felipe Sateler wrote:
>> It seems like Apple has developed a rather interesting parallelization
>> toolkit called Grand Central Dispatch[1]. Furthermore, it has been
>> released as open source[2]. Unfortunately, it has been released under
>> the Apache license which is not compatible with the GPL, and it requires
>> blocks, a compiler feature which is not in gcc yet. It may evolve
>> interestingly, or an alternative GPL-compatible implementation may
>> appear.
>>
>
> Unfortunately it appears to be rather less exciting that hoped. Ditto
> OpenCL (at least, for real-time audio). This is from an Apple developer
> on the CoreAudio list:
>
> "Ehm, you know that GCD is running at the main thread level? Which can
> be blocked by UI operations, etc. That doesn't seem like a wise choice
> for real-time processing. OpenCL also doesn't have a threading mode, so
> you tasks will be shared among all the others and your latency becomes
> unpredictable.
> "
>
> So whatever tasks it may be useful for, parallelizing Csound seems
> unlikely to be one one of them.
>
> Richard Dobson
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus 
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Last time I tried, I massively parallelized a for loop with OpenMP and
the application thrashed my laptop with thousands of threads. So unless
there is some tunable that I missed, OpenMP requires you to know how
many threads to start.

Anyways, the point is that the OS decides how many threads. There is a
global thread pool. In a GCD-ideal world, where everyone uses GCD, then
everything works better: for example, if you have csound and PD running
at the same time, they both share the thread pool. So you do not get
the double number of threads because both apps are threaded.

On Mon, 2009-09-14 at 14:53 -0400, Michael Gogins wrote:
> But OpenMP does the same thing. You declare a parallel block, OpenMP
> implicitly creates a task and automatically figures out a good number
> of threads to run the block in parallel tasks.
> 
> OpenMP can also nest parallel blocks inside parallel blocks.
> 
> Regards,
> Mike
> 
> On 9/14/09, Felipe Sateler  wrote:
> > The main advantage is that csound just issues tasks to be done, it is
> > the OS which takes care of deciding how many threads should be spawned.
> > This way you forget about how managing the threads, but instead manage
> > tasks (which, BTW, can be queued up as a DAG).
> >
> > On Mon, 2009-09-14 at 14:23 -0400, Michael Gogins wrote:
> >> What is the advantage of Grand Central Dispatch over OpenMP, which is
> >> implemented in all compilers used to build Csound?
> >>
> >> Regards,
> >> Mike
> >>
> >> On 9/14/09, Felipe Sateler  wrote:
> >> > It seems like Apple has developed a rather interesting parallelization
> >> > toolkit called Grand Central Dispatch[1]. Furthermore, it has been
> >> > released as open source[2]. Unfortunately, it has been released under
> >> > the Apache license which is not compatible with the GPL, and it requires
> >> > blocks, a compiler feature which is not in gcc yet. It may evolve
> >> > interestingly, or an alternative GPL-compatible implementation may
> >> > appear.
> >> >
> >> >
> >> > [1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
> >> > [2]
> >> > http://arstechnica.com/open-source/news/2009/09/apple-opens-gcd-challenges-impede-adoption-on-linux.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss
> >> >
> >> > --
> >> > Saludos,
> >> > Felipe Sateler
> >> >
> >>
> >>
> > --
> > Saludos,
> > Felipe Sateler
> >
> 
> 
-- 
Saludos,
Felipe Sateler

On Mon, 2009-09-14 at 19:57 +0100, Richard Dobson wrote:
> Felipe Sateler wrote:
> > It seems like Apple has developed a rather interesting parallelization
> > toolkit called Grand Central Dispatch[1]. Furthermore, it has been
> > released as open source[2]. Unfortunately, it has been released under
> > the Apache license which is not compatible with the GPL, and it requires
> > blocks, a compiler feature which is not in gcc yet. It may evolve
> > interestingly, or an alternative GPL-compatible implementation may
> > appear. 
> > 
> 
> Unfortunately it appears to be rather less exciting that hoped. Ditto 
> OpenCL (at least, for real-time audio). This is from an Apple developer 
> on the CoreAudio list:
> 
> "Ehm, you know that GCD is running at the main thread level? Which can 
> be blocked by UI operations, etc. That doesn't seem like a wise choice 
> for real-time processing. OpenCL also doesn't have a threading mode, so 
> you tasks will be shared among all the others and your latency becomes 
> unpredictable.
> "

Not if the UI, etc are on their own thread too. A well parallelized app
could leave the main thread only for thread-handling.

> 
> So whatever tasks it may be useful for, parallelizing Csound seems 
> unlikely to be one one of them.

In its current form, it already isn't, because of license and technical
issues. But it is interesting to see new approaches


-- 
Saludos,
Felipe Sateler

What's the problem with OpenMP? I've used pthreads extensively and
OpenMP just a bit, but OpenMP is considerably easier to use and to
read, once you get used to it -- which doesn't take long. I think
Csound could be made completely parallel during performance AND
completely thread-safe using OpenMP, without a lot of work. I think
all that is required is:

(1) Divide up the instrument instance list by instrument template.

(2) Make each group of instances from the same template into a
parallel block with a wait barrier at the end of each template. Either
use OpenMP reduction in the output opcodes, or use atomic operations
for addition to the output buffer (see next item).

(3) Protect all read/write of Csound data by opcodes either with
critical sections, or with atomic operations.

We already did (1) and (2) with pthreads. The same work would be
slightly simpler and clearer to read with OpenMP, but the real gain
comes with (3) which is much easier to do with OpenMP than with
pthreads. Mostly this is just putting critical sections around the
work done inside Csound API calls.

The only questions I have about this are:

(1) Would there be any deadlocks? I don't see it, but maybe somebody else does?

(2) What is the runtime overhead of (3) above? I expect the cost would
be outweighed by the performance gain.

Regards,
Mike

On 9/14/09, victor  wrote:
> I still think we should keep going with pthreads, possibly considering
> OpenMP in the future. But as the FAUST guys showed, things are not
> straighforward anyway (although I guess they were aiming at a too fine
> level of granularity).
>
> I have great hopes for the system John's been preparing.
>
> Victor
> ----- Original Message -----
> From: "Richard Dobson" 
> To: "Developer discussions" 
> Sent: Monday, September 14, 2009 7:57 PM
> Subject: Re: [Cs-dev] Another parallel toolkit
>
>
>> Felipe Sateler wrote:
>>> It seems like Apple has developed a rather interesting parallelization
>>> toolkit called Grand Central Dispatch[1]. Furthermore, it has been
>>> released as open source[2]. Unfortunately, it has been released under
>>> the Apache license which is not compatible with the GPL, and it requires
>>> blocks, a compiler feature which is not in gcc yet. It may evolve
>>> interestingly, or an alternative GPL-compatible implementation may
>>> appear.
>>>
>>
>> Unfortunately it appears to be rather less exciting that hoped. Ditto
>> OpenCL (at least, for real-time audio). This is from an Apple developer
>> on the CoreAudio list:
>>
>> "Ehm, you know that GCD is running at the main thread level? Which can
>> be blocked by UI operations, etc. That doesn't seem like a wise choice
>> for real-time processing. OpenCL also doesn't have a threading mode, so
>> you tasks will be shared among all the others and your latency becomes
>> unpredictable.
>> "
>>
>> So whatever tasks it may be useful for, parallelizing Csound seems
>> unlikely to be one one of them.
>>
>> Richard Dobson
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>>
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The reason is that while all this work needs to be done, tested
and thought through, the pthreads-based parallel engine is already
being developed and showed encouraging results.

Victor
----- Original Message ----- 
From: "Michael Gogins" 
To: "Developer discussions" 
Cc: 
Sent: Monday, September 14, 2009 8:46 PM
Subject: Re: [Cs-dev] Another parallel toolkit


> What's the problem with OpenMP? I've used pthreads extensively and
> OpenMP just a bit, but OpenMP is considerably easier to use and to
> read, once you get used to it -- which doesn't take long. I think
> Csound could be made completely parallel during performance AND
> completely thread-safe using OpenMP, without a lot of work. I think
> all that is required is:
>
> (1) Divide up the instrument instance list by instrument template.
>
> (2) Make each group of instances from the same template into a
> parallel block with a wait barrier at the end of each template. Either
> use OpenMP reduction in the output opcodes, or use atomic operations
> for addition to the output buffer (see next item).
>
> (3) Protect all read/write of Csound data by opcodes either with
> critical sections, or with atomic operations.
>
> We already did (1) and (2) with pthreads. The same work would be
> slightly simpler and clearer to read with OpenMP, but the real gain
> comes with (3) which is much easier to do with OpenMP than with
> pthreads. Mostly this is just putting critical sections around the
> work done inside Csound API calls.
>
> The only questions I have about this are:
>
> (1) Would there be any deadlocks? I don't see it, but maybe somebody else 
> does?
>
> (2) What is the runtime overhead of (3) above? I expect the cost would
> be outweighed by the performance gain.
>
> Regards,
> Mike
>
> On 9/14/09, victor  wrote:
>> I still think we should keep going with pthreads, possibly considering
>> OpenMP in the future. But as the FAUST guys showed, things are not
>> straighforward anyway (although I guess they were aiming at a too fine
>> level of granularity).
>>
>> I have great hopes for the system John's been preparing.
>>
>> Victor
>> ----- Original Message -----
>> From: "Richard Dobson" 
>> To: "Developer discussions" 
>> Sent: Monday, September 14, 2009 7:57 PM
>> Subject: Re: [Cs-dev] Another parallel toolkit
>>
>>
>>> Felipe Sateler wrote:
>>>> It seems like Apple has developed a rather interesting parallelization
>>>> toolkit called Grand Central Dispatch[1]. Furthermore, it has been
>>>> released as open source[2]. Unfortunately, it has been released under
>>>> the Apache license which is not compatible with the GPL, and it 
>>>> requires
>>>> blocks, a compiler feature which is not in gcc yet. It may evolve
>>>> interestingly, or an alternative GPL-compatible implementation may
>>>> appear.
>>>>
>>>
>>> Unfortunately it appears to be rather less exciting that hoped. Ditto
>>> OpenCL (at least, for real-time audio). This is from an Apple developer
>>> on the CoreAudio list:
>>>
>>> "Ehm, you know that GCD is running at the main thread level? Which can
>>> be blocked by UI operations, etc. That doesn't seem like a wise choice
>>> for real-time processing. OpenCL also doesn't have a threading mode, so
>>> you tasks will be shared among all the others and your latency becomes
>>> unpredictable.
>>> "
>>>
>>> So whatever tasks it may be useful for, parallelizing Csound seems
>>> unlikely to be one one of them.
>>>
>>> Richard Dobson
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and 
>>> focus
>>>
>>> on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and 
>> focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus 
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks for the info!

Rory.


2009/9/12 kelly  hirai :
> hey all,
>
> if you get the following error using the wii opcodes:
>
> [INFO] Found 1 bluetooth device(s).
> [INFO] Found wiimote (00:1F:32:F1:8D:0C) [id 1].
> connect() output sock: Invalid argument
> Failed to connect to any wiimote.
>
> Michael LaForest suggests modifing the source of libwiiuse in the following
> way:
>
> memset(&addr, 0, sizeof (addr)); //is missing in the line 174 of io_nix.c
>
> it worked for me.
>
> kelly hirai
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"