This looks nice Matt, well done. Unfortunetely I don't have an iphone
but I'll let those of my friends who have one know. It's a real pity
you had no success in getting Csound to run on it, that would have
been really great. So great in fact I would have even considered
getting one myself.

Rory.


On 17 June 2010 20:06, matt ingalls  wrote:
> hi csounders:
> i thought ya'll might be interested in my new iPhone synth app:
> http://sonomatics.com/aardvark.html
> http://itunes.apple.com/app/aardvark-synth/id376868549?mt=8
> i would really appreciate it if you could pass it along to anyone
> you might think would be interested.
> -----------
> btw, i gave up trying to get csound compiled for iphoneos..
> instead i have written my own C++ synthesis framework (!!!)
> lots of ideas using it (relating/using csound) hopefully i can get to them
> before
> my savings runs out and i start looking for work...
>
> THANKS!
> ma++


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

thanks rory.
(moved this to dev list)

yeah, too daunting to deal with all the dynamic libs 
(which are not allowed on iphone)

android phone is the way to go, i think.   but be warned, phone cpu speed is pretty disappointing coming from desktop.. :(
-m

On Jun 17, 2010, at 2:11 PM, Rory Walsh wrote:

> This looks nice Matt, well done. Unfortunetely I don't have an iphone
> but I'll let those of my friends who have one know. It's a real pity
> you had no success in getting Csound to run on it, that would have
> been really great. So great in fact I would have even considered
> getting one myself.
> 
> Rory.
> 
> 
> On 17 June 2010 20:06, matt ingalls  wrote:
>> hi csounders:
>> i thought ya'll might be interested in my new iPhone synth app:
>> http://sonomatics.com/aardvark.html
>> http://itunes.apple.com/app/aardvark-synth/id376868549?mt=8
>> i would really appreciate it if you could pass it along to anyone
>> you might think would be interested.
>> -----------
>> btw, i gave up trying to get csound compiled for iphoneos..
>> instead i have written my own C++ synthesis framework (!!!)
>> lots of ideas using it (relating/using csound) hopefully i can get to them
>> before
>> my savings runs out and i start looking for work...
>> 
>> THANKS!
>> ma++
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The sources could be linked into one executable, unless the license forbids it.

Regards,
Mike

On Thu, Jun 17, 2010 at 7:13 PM, Greg Schroeder  wrote:
> How on earth would one use csound on an iphone?
> Greg
>
> On Fri, Jun 18, 2010 at 6:11 AM, Rory Walsh  wrote:
>>
>> This looks nice Matt, well done. Unfortunetely I don't have an iphone
>> but I'll let those of my friends who have one know. It's a real pity
>> you had no success in getting Csound to run on it, that would have
>> been really great. So great in fact I would have even considered
>> getting one myself.
>>
>> Rory.
>>
>>
>> On 17 June 2010 20:06, matt ingalls  wrote:
>> > hi csounders:
>> > i thought ya'll might be interested in my new iPhone synth app:
>> > http://sonomatics.com/aardvark.html
>> > http://itunes.apple.com/app/aardvark-synth/id376868549?mt=8
>> > i would really appreciate it if you could pass it along to anyone
>> > you might think would be interested.
>> > -----------
>> > btw, i gave up trying to get csound compiled for iphoneos..
>> > instead i have written my own C++ synthesis framework (!!!)
>> > lots of ideas using it (relating/using csound) hopefully i can get to
>> > them
>> > before
>> > my savings runs out and i start looking for work...
>> >
>> > THANKS!
>> > ma++
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>



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


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 18/06/2010 00:32, matt ingalls wrote:
> video: http://vimeo.com/12637712
>
> you program the iphone in C [ technically, objective-C++ ]
>

And, for example, as I noted in another thread, Perry Cook's Synthesis 
Toolkit (STK), vanilla C++, just builds in the usual way as a static 
library and works as expected.

Any statically linked version of Csound should build (unlikely that the 
computationally heavy opcodes such as pvs and other FFT-based opcodes 
would run in real-time so would be left out; ditto any GUI stuff such as 
FLTK,and very likely the MIDI stuff would go as well). So, ironically, 
the older 4.x distributions which were built as a single large 
executable would likely be easier to build than the modern versions 
based on umpteen shared libraries.  You would need the API though (or 
some reduced version of it), so that perf loop calls can be invoked from 
the CoreAudio end of things. Still a lot of work; and I can well 
understand that it might be more straight-forward to "roll one's own".

Richard Dobson



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> 
> Any statically linked version of Csound should build (unlikely that the computationally heavy opcodes such as pvs and other FFT-based opcodes would run in real-time so would be left out; ditto any GUI stuff such as FLTK,and very likely the MIDI stuff would go as well). So, ironically, the older 4.x distributions which were built as a single large executable would likely be easier to build than the modern versions based on umpteen shared libraries.  You would need the API though (or some reduced version of it), so that perf loop calls can be invoked from the CoreAudio end of things. Still a lot of work; and I can well understand that it might be more straight-forward to "roll one's own".

exactly.....  not fun!   
and add to that, (you may not remember) but back in the day, i *strongly* advocated to NOT move opcodes to dynamic libs (one of many battles lost).  so the whole project was becoming pretty unappealing and then i realized it would take just as much time to just write my own, *modern* toolkit with the basic synth/dsp ugens -- it's been fun, seems reasonably efficient, and i have to say, liberating...  now some of these other projects ive been wanting to make seem possible without having to rely on CsoundLib :)

-m


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It is no big deal to move the opcodes back into a statically linked
Csound. In addition to building the opcodes objects and linking them,
which just means adding them to the list of files in SConstruct (and
any required libraries to the link line), you need to register them.
This can be done in several ways.

The most straightforward way is to copy and paste the opcode entry
structures and add them to the global opcode list (inside #ifdefs for
an all-static build, of course).

Another way is to call each module's csoundModuleInit function. For
this to work without name collisions, you could create some macros.
One would, if #ifdef'd for all-static build, rename the module
initialization function by prefixing it with part of the filename
macro. The other would, if #ifdef'd for all-static build, supplement
the reading of the opcode list with calling all the otherwise
dynamically loaded modules' initialization functions.

A third way is to supplement Csound's module loading code to be more
like other dynamic languages with plugins. Instead of just
csoundModuleInit, the module initialization function could optionally
be named csoundModuleInit_BASENAME. Then in an all-static build, a
list of these functions would be called; in a dynamic build, the
function names would be built off the file's basename and then called.
This does the same thing as the second option, but without macros.

Regards,
Mike


On Fri, Jun 18, 2010 at 1:44 PM, matt ingalls  wrote:
>>
>> Any statically linked version of Csound should build (unlikely that the computationally heavy opcodes such as pvs and other FFT-based opcodes would run in real-time so would be left out; ditto any GUI stuff such as FLTK,and very likely the MIDI stuff would go as well). So, ironically, the older 4.x distributions which were built as a single large executable would likely be easier to build than the modern versions based on umpteen shared libraries.  You would need the API though (or some reduced version of it), so that perf loop calls can be invoked from the CoreAudio end of things. Still a lot of work; and I can well understand that it might be more straight-forward to "roll one's own".
>
> exactly.....  not fun!
> and add to that, (you may not remember) but back in the day, i *strongly* advocated to NOT move opcodes to dynamic libs (one of many battles lost).  so the whole project was becoming pretty unappealing and then i realized it would take just as much time to just write my own, *modern* toolkit with the basic synth/dsp ugens -- it's been fun, seems reasonably efficient, and i have to say, liberating...  now some of these other projects ive been wanting to make seem possible without having to rely on CsoundLib :)
>
> -m
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It's funny that when all modern operating systems move towards use of  
shared libraries, the iPhone OS shuns them.

Victor

On 18 Jun 2010, at 19:23, Michael Gogins wrote:

> It is no big deal to move the opcodes back into a statically linked
> Csound. In addition to building the opcodes objects and linking them,
> which just means adding them to the list of files in SConstruct (and
> any required libraries to the link line), you need to register them.
> This can be done in several ways.
>
> The most straightforward way is to copy and paste the opcode entry
> structures and add them to the global opcode list (inside #ifdefs for
> an all-static build, of course).
>
> Another way is to call each module's csoundModuleInit function. For
> this to work without name collisions, you could create some macros.
> One would, if #ifdef'd for all-static build, rename the module
> initialization function by prefixing it with part of the filename
> macro. The other would, if #ifdef'd for all-static build, supplement
> the reading of the opcode list with calling all the otherwise
> dynamically loaded modules' initialization functions.
>
> A third way is to supplement Csound's module loading code to be more
> like other dynamic languages with plugins. Instead of just
> csoundModuleInit, the module initialization function could optionally
> be named csoundModuleInit_BASENAME. Then in an all-static build, a
> list of these functions would be called; in a dynamic build, the
> function names would be built off the file's basename and then called.
> This does the same thing as the second option, but without macros.
>
> Regards,
> Mike
>
>
> On Fri, Jun 18, 2010 at 1:44 PM, matt ingalls   
> wrote:
>>>
>>> Any statically linked version of Csound should build (unlikely  
>>> that the computationally heavy opcodes such as pvs and other FFT- 
>>> based opcodes would run in real-time so would be left out; ditto  
>>> any GUI stuff such as FLTK,and very likely the MIDI stuff would go  
>>> as well). So, ironically, the older 4.x distributions which were  
>>> built as a single large executable would likely be easier to build  
>>> than the modern versions based on umpteen shared libraries.  You  
>>> would need the API though (or some reduced version of it), so that  
>>> perf loop calls can be invoked from the CoreAudio end of things.  
>>> Still a lot of work; and I can well understand that it might be  
>>> more straight-forward to "roll one's own".
>>
>> exactly.....  not fun!
>> and add to that, (you may not remember) but back in the day, i  
>> *strongly* advocated to NOT move opcodes to dynamic libs (one of  
>> many battles lost).  so the whole project was becoming pretty  
>> unappealing and then i realized it would take just as much time to  
>> just write my own, *modern* toolkit with the basic synth/dsp ugens  
>> -- it's been fun, seems reasonably efficient, and i have to say,  
>> liberating...  now some of these other projects ive been wanting to  
>> make seem possible without having to rely on CsoundLib :)
>>
>> -m
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm all for reintegrating all opcodes that do not rely on 3rd party
libs back into csound. It would certainly help for packaging csound
for use over the web via Java.

On 6/18/10, Michael Gogins  wrote:
> It is no big deal to move the opcodes back into a statically linked
> Csound. In addition to building the opcodes objects and linking them,
> which just means adding them to the list of files in SConstruct (and
> any required libraries to the link line), you need to register them.
> This can be done in several ways.
>
> The most straightforward way is to copy and paste the opcode entry
> structures and add them to the global opcode list (inside #ifdefs for
> an all-static build, of course).
>
> Another way is to call each module's csoundModuleInit function. For
> this to work without name collisions, you could create some macros.
> One would, if #ifdef'd for all-static build, rename the module
> initialization function by prefixing it with part of the filename
> macro. The other would, if #ifdef'd for all-static build, supplement
> the reading of the opcode list with calling all the otherwise
> dynamically loaded modules' initialization functions.
>
> A third way is to supplement Csound's module loading code to be more
> like other dynamic languages with plugins. Instead of just
> csoundModuleInit, the module initialization function could optionally
> be named csoundModuleInit_BASENAME. Then in an all-static build, a
> list of these functions would be called; in a dynamic build, the
> function names would be built off the file's basename and then called.
> This does the same thing as the second option, but without macros.
>
> Regards,
> Mike
>
>
> On Fri, Jun 18, 2010 at 1:44 PM, matt ingalls  wrote:
>>>
>>> Any statically linked version of Csound should build (unlikely that the
>>> computationally heavy opcodes such as pvs and other FFT-based opcodes
>>> would run in real-time so would be left out; ditto any GUI stuff such as
>>> FLTK,and very likely the MIDI stuff would go as well). So, ironically,
>>> the older 4.x distributions which were built as a single large executable
>>> would likely be easier to build than the modern versions based on umpteen
>>> shared libraries.  You would need the API though (or some reduced version
>>> of it), so that perf loop calls can be invoked from the CoreAudio end of
>>> things. Still a lot of work; and I can well understand that it might be
>>> more straight-forward to "roll one's own".
>>
>> exactly.....  not fun!
>> and add to that, (you may not remember) but back in the day, i *strongly*
>> advocated to NOT move opcodes to dynamic libs (one of many battles lost).
>>  so the whole project was becoming pretty unappealing and then i realized
>> it would take just as much time to just write my own, *modern* toolkit
>> with the basic synth/dsp ugens -- it's been fun, seems reasonably
>> efficient, and i have to say, liberating...  now some of these other
>> projects ive been wanting to make seem possible without having to rely on
>> CsoundLib :)
>>
>> -m
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-- 
Sent from my mobile device

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Surely there is in fact some way to use shared libraries in an iPhone
app? The iPhone SDK states that the operating system itself, and Apple
frameworks, contain shared libraries. I would guess that it is in fact
technically possible to build a shared library, digitally sign it,
install it in the application sandbox (i.e. create a Csound
Framework), and call it.

But according to the iPhone SDK developer agreement on WikiLeaks, this
is not LEGALLY possible. (There may also be hidden restrictions in the
OS that prevent loading dynamic libraries outside of specific
Frameworks, but forbidding it legally seems to imply that it is
techncially possible).

I can understand the use of application sandboxes for added security,
but preventing the use of signed shared libraries inside a sandbox
goes beyond security and what looks to me like a belief that "Apple
knows best" that translates into a desire to dominate users.

Frankly, I think Apple is pushing computing in a very undesirable
direction. I advise everyone to avoid Apple and all its products ---
even though they are very well made and lots of fun.

Regards,
Mike

On Fri, Jun 18, 2010 at 2:28 PM, Victor Lazzarini
 wrote:
> It's funny that when all modern operating systems move towards use of
> shared libraries, the iPhone OS shuns them.
>
> Victor
>
> On 18 Jun 2010, at 19:23, Michael Gogins wrote:
>
>> It is no big deal to move the opcodes back into a statically linked
>> Csound. In addition to building the opcodes objects and linking them,
>> which just means adding them to the list of files in SConstruct (and
>> any required libraries to the link line), you need to register them.
>> This can be done in several ways.
>>
>> The most straightforward way is to copy and paste the opcode entry
>> structures and add them to the global opcode list (inside #ifdefs for
>> an all-static build, of course).
>>
>> Another way is to call each module's csoundModuleInit function. For
>> this to work without name collisions, you could create some macros.
>> One would, if #ifdef'd for all-static build, rename the module
>> initialization function by prefixing it with part of the filename
>> macro. The other would, if #ifdef'd for all-static build, supplement
>> the reading of the opcode list with calling all the otherwise
>> dynamically loaded modules' initialization functions.
>>
>> A third way is to supplement Csound's module loading code to be more
>> like other dynamic languages with plugins. Instead of just
>> csoundModuleInit, the module initialization function could optionally
>> be named csoundModuleInit_BASENAME. Then in an all-static build, a
>> list of these functions would be called; in a dynamic build, the
>> function names would be built off the file's basename and then called.
>> This does the same thing as the second option, but without macros.
>>
>> Regards,
>> Mike
>>
>>
>> On Fri, Jun 18, 2010 at 1:44 PM, matt ingalls 
>> wrote:
>>>>
>>>> Any statically linked version of Csound should build (unlikely
>>>> that the computationally heavy opcodes such as pvs and other FFT-
>>>> based opcodes would run in real-time so would be left out; ditto
>>>> any GUI stuff such as FLTK,and very likely the MIDI stuff would go
>>>> as well). So, ironically, the older 4.x distributions which were
>>>> built as a single large executable would likely be easier to build
>>>> than the modern versions based on umpteen shared libraries.  You
>>>> would need the API though (or some reduced version of it), so that
>>>> perf loop calls can be invoked from the CoreAudio end of things.
>>>> Still a lot of work; and I can well understand that it might be
>>>> more straight-forward to "roll one's own".
>>>
>>> exactly.....  not fun!
>>> and add to that, (you may not remember) but back in the day, i
>>> *strongly* advocated to NOT move opcodes to dynamic libs (one of
>>> many battles lost).  so the whole project was becoming pretty
>>> unappealing and then i realized it would take just as much time to
>>> just write my own, *modern* toolkit with the basic synth/dsp ugens
>>> -- it's been fun, seems reasonably efficient, and i have to say,
>>> liberating...  now some of these other projects ive been wanting to
>>> make seem possible without having to rely on CsoundLib :)
>>>
>>> -m
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> 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
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Agreed, I'm all for looking into Android as a real possibility for  
mobile audio applications.

Victor
On 18 Jun 2010, at 19:54, Michael Gogins wrote:

> Surely there is in fact some way to use shared libraries in an iPhone
> app? The iPhone SDK states that the operating system itself, and Apple
> frameworks, contain shared libraries. I would guess that it is in fact
> technically possible to build a shared library, digitally sign it,
> install it in the application sandbox (i.e. create a Csound
> Framework), and call it.
>
> But according to the iPhone SDK developer agreement on WikiLeaks, this
> is not LEGALLY possible. (There may also be hidden restrictions in the
> OS that prevent loading dynamic libraries outside of specific
> Frameworks, but forbidding it legally seems to imply that it is
> techncially possible).
>
> I can understand the use of application sandboxes for added security,
> but preventing the use of signed shared libraries inside a sandbox
> goes beyond security and what looks to me like a belief that "Apple
> knows best" that translates into a desire to dominate users.
>
> Frankly, I think Apple is pushing computing in a very undesirable
> direction. I advise everyone to avoid Apple and all its products ---
> even though they are very well made and lots of fun.
>
> Regards,
> Mike
>
> On Fri, Jun 18, 2010 at 2:28 PM, Victor Lazzarini
>  wrote:
>> It's funny that when all modern operating systems move towards use of
>> shared libraries, the iPhone OS shuns them.
>>
>> Victor
>>
>> On 18 Jun 2010, at 19:23, Michael Gogins wrote:
>>
>>> It is no big deal to move the opcodes back into a statically linked
>>> Csound. In addition to building the opcodes objects and linking  
>>> them,
>>> which just means adding them to the list of files in SConstruct (and
>>> any required libraries to the link line), you need to register them.
>>> This can be done in several ways.
>>>
>>> The most straightforward way is to copy and paste the opcode entry
>>> structures and add them to the global opcode list (inside #ifdefs  
>>> for
>>> an all-static build, of course).
>>>
>>> Another way is to call each module's csoundModuleInit function. For
>>> this to work without name collisions, you could create some macros.
>>> One would, if #ifdef'd for all-static build, rename the module
>>> initialization function by prefixing it with part of the filename
>>> macro. The other would, if #ifdef'd for all-static build, supplement
>>> the reading of the opcode list with calling all the otherwise
>>> dynamically loaded modules' initialization functions.
>>>
>>> A third way is to supplement Csound's module loading code to be more
>>> like other dynamic languages with plugins. Instead of just
>>> csoundModuleInit, the module initialization function could  
>>> optionally
>>> be named csoundModuleInit_BASENAME. Then in an all-static build, a
>>> list of these functions would be called; in a dynamic build, the
>>> function names would be built off the file's basename and then  
>>> called.
>>> This does the same thing as the second option, but without macros.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> On Fri, Jun 18, 2010 at 1:44 PM, matt ingalls 
>>> wrote:
>>>>>
>>>>> Any statically linked version of Csound should build (unlikely
>>>>> that the computationally heavy opcodes such as pvs and other FFT-
>>>>> based opcodes would run in real-time so would be left out; ditto
>>>>> any GUI stuff such as FLTK,and very likely the MIDI stuff would go
>>>>> as well). So, ironically, the older 4.x distributions which were
>>>>> built as a single large executable would likely be easier to build
>>>>> than the modern versions based on umpteen shared libraries.  You
>>>>> would need the API though (or some reduced version of it), so that
>>>>> perf loop calls can be invoked from the CoreAudio end of things.
>>>>> Still a lot of work; and I can well understand that it might be
>>>>> more straight-forward to "roll one's own".
>>>>
>>>> exactly.....  not fun!
>>>> and add to that, (you may not remember) but back in the day, i
>>>> *strongly* advocated to NOT move opcodes to dynamic libs (one of
>>>> many battles lost).  so the whole project was becoming pretty
>>>> unappealing and then i realized it would take just as much time to
>>>> just write my own, *modern* toolkit with the basic synth/dsp ugens
>>>> -- it's been fun, seems reasonably efficient, and i have to say,
>>>> liberating...  now some of these other projects ive been wanting to
>>>> make seem possible without having to rely on CsoundLib :)
>>>>
>>>> -m
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>> _______________________________________________
>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What about porting the olpc version of csound to mobile?

On Fri, Jun 18, 2010 at 1:27 AM, Richard Dobson
 wrote:
> On 18/06/2010 00:32, matt ingalls wrote:
>>
>> video: http://vimeo.com/12637712
>>
>> you program the iphone in C [ technically, objective-C++ ]
>>
>
> And, for example, as I noted in another thread, Perry Cook's Synthesis
> Toolkit (STK), vanilla C++, just builds in the usual way as a static library
> and works as expected.
>
> Any statically linked version of Csound should build (unlikely that the
> computationally heavy opcodes such as pvs and other FFT-based opcodes would
> run in real-time so would be left out; ditto any GUI stuff such as FLTK,and
> very likely the MIDI stuff would go as well). So, ironically, the older 4.x
> distributions which were built as a single large executable would likely be
> easier to build than the modern versions based on umpteen shared libraries.
>  You would need the API though (or some reduced version of it), so that perf
> loop calls can be invoked from the CoreAudio end of things. Still a lot of
> work; and I can well understand that it might be more straight-forward to
> "roll one's own".
>
> Richard Dobson
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

yeah, it definitely made sense to get the "plugin" architecture,
but moving all the canonical opcodes to dlls never made sense to me.
plus really is an obstacle for people like me who prefer using IDEs instead of scons.

(hi steven!)


On Jun 18, 2010, at 11:39 AM, Steven Yi wrote:

> I'm all for reintegrating all opcodes that do not rely on 3rd party
> libs back into csound. It would certainly help for packaging csound
> for use over the web via Java.
> 
> On 6/18/10, Michael Gogins  wrote:
>> It is no big deal to move the opcodes back into a statically linked
>> Csound. In addition to building the opcodes objects and linking them,
>> which just means adding them to the list of files in SConstruct (and
>> any required libraries to the link line), you need to register them.
>> This can be done in several ways.
>> 
>> The most straightforward way is to copy and paste the opcode entry
>> structures and add them to the global opcode list (inside #ifdefs for
>> an all-static build, of course).
>> 
>> Another way is to call each module's csoundModuleInit function. For
>> this to work without name collisions, you could create some macros.
>> One would, if #ifdef'd for all-static build, rename the module
>> initialization function by prefixing it with part of the filename
>> macro. The other would, if #ifdef'd for all-static build, supplement
>> the reading of the opcode list with calling all the otherwise
>> dynamically loaded modules' initialization functions.
>> 
>> A third way is to supplement Csound's module loading code to be more
>> like other dynamic languages with plugins. Instead of just
>> csoundModuleInit, the module initialization function could optionally
>> be named csoundModuleInit_BASENAME. Then in an all-static build, a
>> list of these functions would be called; in a dynamic build, the
>> function names would be built off the file's basename and then called.
>> This does the same thing as the second option, but without macros.
>> 
>> Regards,
>> Mike
>> 
>> 
>> On Fri, Jun 18, 2010 at 1:44 PM, matt ingalls  wrote:
>>>> 
>>>> Any statically linked version of Csound should build (unlikely that the
>>>> computationally heavy opcodes such as pvs and other FFT-based opcodes
>>>> would run in real-time so would be left out; ditto any GUI stuff such as
>>>> FLTK,and very likely the MIDI stuff would go as well). So, ironically,
>>>> the older 4.x distributions which were built as a single large executable
>>>> would likely be easier to build than the modern versions based on umpteen
>>>> shared libraries.  You would need the API though (or some reduced version
>>>> of it), so that perf loop calls can be invoked from the CoreAudio end of
>>>> things. Still a lot of work; and I can well understand that it might be
>>>> more straight-forward to "roll one's own".
>>> 
>>> exactly.....  not fun!
>>> and add to that, (you may not remember) but back in the day, i *strongly*
>>> advocated to NOT move opcodes to dynamic libs (one of many battles lost).
>>>  so the whole project was becoming pretty unappealing and then i realized
>>> it would take just as much time to just write my own, *modern* toolkit
>>> with the basic synth/dsp ugens -- it's been fun, seems reasonably
>>> efficient, and i have to say, liberating...  now some of these other
>>> projects ive been wanting to make seem possible without having to rely on
>>> CsoundLib :)
>>> 
>>> -m
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> 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
>> 
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> -- 
> Sent from my mobile device
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Matt! :)

I was thinking it'd be nice to use IDE too. I was thinking of trying
to setup something for Netbeans a while back but never got around to
it. BTW: I've been doing iPhone dev the past half year and have to say
I'm not the biggest XCode fan. :P

Steven

On 6/18/10, matt ingalls  wrote:
> yeah, it definitely made sense to get the "plugin" architecture,
> but moving all the canonical opcodes to dlls never made sense to me.
> plus really is an obstacle for people like me who prefer using IDEs instead
> of scons.
>
> (hi steven!)
>
>
> On Jun 18, 2010, at 11:39 AM, Steven Yi wrote:
>
>> I'm all for reintegrating all opcodes that do not rely on 3rd party
>> libs back into csound. It would certainly help for packaging csound
>> for use over the web via Java.
>>
>> On 6/18/10, Michael Gogins  wrote:
>>> It is no big deal to move the opcodes back into a statically linked
>>> Csound. In addition to building the opcodes objects and linking them,
>>> which just means adding them to the list of files in SConstruct (and
>>> any required libraries to the link line), you need to register them.
>>> This can be done in several ways.
>>>
>>> The most straightforward way is to copy and paste the opcode entry
>>> structures and add them to the global opcode list (inside #ifdefs for
>>> an all-static build, of course).
>>>
>>> Another way is to call each module's csoundModuleInit function. For
>>> this to work without name collisions, you could create some macros.
>>> One would, if #ifdef'd for all-static build, rename the module
>>> initialization function by prefixing it with part of the filename
>>> macro. The other would, if #ifdef'd for all-static build, supplement
>>> the reading of the opcode list with calling all the otherwise
>>> dynamically loaded modules' initialization functions.
>>>
>>> A third way is to supplement Csound's module loading code to be more
>>> like other dynamic languages with plugins. Instead of just
>>> csoundModuleInit, the module initialization function could optionally
>>> be named csoundModuleInit_BASENAME. Then in an all-static build, a
>>> list of these functions would be called; in a dynamic build, the
>>> function names would be built off the file's basename and then called.
>>> This does the same thing as the second option, but without macros.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> On Fri, Jun 18, 2010 at 1:44 PM, matt ingalls 
>>> wrote:
>>>>>
>>>>> Any statically linked version of Csound should build (unlikely that the
>>>>> computationally heavy opcodes such as pvs and other FFT-based opcodes
>>>>> would run in real-time so would be left out; ditto any GUI stuff such
>>>>> as
>>>>> FLTK,and very likely the MIDI stuff would go as well). So, ironically,
>>>>> the older 4.x distributions which were built as a single large
>>>>> executable
>>>>> would likely be easier to build than the modern versions based on
>>>>> umpteen
>>>>> shared libraries.  You would need the API though (or some reduced
>>>>> version
>>>>> of it), so that perf loop calls can be invoked from the CoreAudio end
>>>>> of
>>>>> things. Still a lot of work; and I can well understand that it might be
>>>>> more straight-forward to "roll one's own".
>>>>
>>>> exactly.....  not fun!
>>>> and add to that, (you may not remember) but back in the day, i
>>>> *strongly*
>>>> advocated to NOT move opcodes to dynamic libs (one of many battles
>>>> lost).
>>>>  so the whole project was becoming pretty unappealing and then i
>>>> realized
>>>> it would take just as much time to just write my own, *modern* toolkit
>>>> with the basic synth/dsp ugens -- it's been fun, seems reasonably
>>>> efficient, and i have to say, liberating...  now some of these other
>>>> projects ive been wanting to make seem possible without having to rely
>>>> on
>>>> CsoundLib :)
>>>>
>>>> -m
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>> _______________________________________________
>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> --
>> Sent from my mobile device
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-- 
Sent from my mobile device

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net