iphone

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

iphone

Nathan Ho
hi folks,

does supercollider for iphone work anymore? i get the sense that it's no
longer really maintained or used.


nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: iphone

amindfv
There's someone in NYC who at least last year was using it. I can ask him to chime in here.

On Sat, Jan 27, 2018 at 5:11 PM, <[hidden email]> wrote:
hi folks,

does supercollider for iphone work anymore? i get the sense that it's no longer really maintained or used.


nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Reply | Threaded
Open this post in threaded view
|

Re: iphone

dreeder
In reply to this post by Nathan Ho



One of the best ports I have seen comes from Tokyo University of
Technology and Watanabe-DENKI, circa 2015:

    http://kengolab.net/CreApp/wiki/public/document/isc
    http://wdkk.co.jp


See links on kegolab.net for GitHub and a paper from ICMC 2015:

    https://github.com/wdkk/iSuperColliderKit

    http://quod.lib.umich.edu/cgi/p/pod/dod-idx/isupercolliderkit-a-toolkit-for-ios-using-an-internal.pdf?c=icmc;idno=bbp2372.2015.047


It is lightweight and flexible.  Offers maximal control over SuperCollider
with minimal API.

Would be nice to keep this alive.  I suggest we make an effort to
integrate their repo as a means of minimizing the work necessary to keep
the port current as iOS devices and framework generations come and go.



Best,
david





        ###

[hidden email] writes on Sat, 27 Jan 2018 14:11:03 -0800:
.
. hi folks,
.
. does supercollider for iphone work anymore? i get the sense that it's no
. longer really maintained or used.
.
.
. nathan
.


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: iphone

brianlheim
> Would be nice to keep this alive.  I suggest we make an effort to
> integrate their repo as a means of minimizing the work necessary to keep
> the port current as iOS devices and framework generations come and go.

Of the two repos linked in the paper, this is the only one that still exists:

https://github.com/wdkk/iSuperColliderKit

It has no commit history in common with the SC repo, no clear summary of what's been changed. Looking at Readme.txt it was forked from version 3.4. Looking at the commit history, there are new frameworks being introduced and diffs of more than 100k LOC per commit. How exactly do you propose to integrate this?

-Brian


On Sun, Feb 4, 2018 at 11:01 PM, <[hidden email]> wrote:



One of the best ports I have seen comes from Tokyo University of
Technology and Watanabe-DENKI, circa 2015:

    http://kengolab.net/CreApp/wiki/public/document/isc
    http://wdkk.co.jp


See links on kegolab.net for GitHub and a paper from ICMC 2015:

    https://github.com/wdkk/iSuperColliderKit

    http://quod.lib.umich.edu/cgi/p/pod/dod-idx/isupercolliderkit-a-toolkit-for-ios-using-an-internal.pdf?c=icmc;idno=bbp2372.2015.047


It is lightweight and flexible.  Offers maximal control over SuperCollider
with minimal API.

Would be nice to keep this alive.  I suggest we make an effort to
integrate their repo as a means of minimizing the work necessary to keep
the port current as iOS devices and framework generations come and go.



Best,
david





        ###

[hidden email] writes on Sat, 27 Jan 2018 14:11:03 -0800:
.
. hi folks,
.
. does supercollider for iphone work anymore? i get the sense that it's no
. longer really maintained or used.
.
.
. nathan
.


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Reply | Threaded
Open this post in threaded view
|

Re: iphone

Josh Parmenter
First - there are obstacles to releasing any form of SC actually to the store. Second, the approach that would make the most sense would be some sort of version of libscsynth.

That all being said, I have made a few apps that send OSC that I can then connect to a laptop, etc., I don’t know what I would get from an iPad or iPhone that I wouldn’t get from a laptop, so I’m not sure what worth a port would even really have (unless it was a synth engine I could embed into my own apps - which isn’t possible!). So - that all being said - what use case do you see of having it work on iPhone? If there is something compelling and you can get the rest of the sc-dev community to agree, I’d be more than happy to help make it happen. I just don’t know what would convince me, at this point, for the effort. Not to put a hammer down or anything, I’m just not sure what it would get you.

Best,

Josh


On Feb 4, 2018, at 8:55 PM, [hidden email] wrote:

> Would be nice to keep this alive.  I suggest we make an effort to
> integrate their repo as a means of minimizing the work necessary to keep
> the port current as iOS devices and framework generations come and go.

Of the two repos linked in the paper, this is the only one that still exists:

https://github.com/wdkk/iSuperColliderKit

It has no commit history in common with the SC repo, no clear summary of what's been changed. Looking at Readme.txt it was forked from version 3.4. Looking at the commit history, there are new frameworks being introduced and diffs of more than 100k LOC per commit. How exactly do you propose to integrate this?

-Brian


On Sun, Feb 4, 2018 at 11:01 PM, <[hidden email]> wrote:



One of the best ports I have seen comes from Tokyo University of
Technology and Watanabe-DENKI, circa 2015:

    http://kengolab.net/CreApp/wiki/public/document/isc
    http://wdkk.co.jp


See links on kegolab.net for GitHub and a paper from ICMC 2015:

    https://github.com/wdkk/iSuperColliderKit

    http://quod.lib.umich.edu/cgi/p/pod/dod-idx/isupercolliderkit-a-toolkit-for-ios-using-an-internal.pdf?c=icmc;idno=bbp2372.2015.047


It is lightweight and flexible.  Offers maximal control over SuperCollider
with minimal API.

Would be nice to keep this alive.  I suggest we make an effort to
integrate their repo as a means of minimizing the work necessary to keep
the port current as iOS devices and framework generations come and go.



Best,
david





        ###

[hidden email] writes on Sat, 27 Jan 2018 14:11:03 -0800:
.
. hi folks,
.
. does supercollider for iphone work anymore? i get the sense that it's no
. longer really maintained or used.
.
.
. nathan
.


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


Reply | Threaded
Open this post in threaded view
|

Re: iphone

dreeder



Re: Integrating or linking iSCKit into main SC repo.  Integrating this
repo is not trivial, to be sure.  I'm also thinking big picture: would
be great to preserve this functionality.  We know it is built on top of
SC, dependent upon SC in some form.  Maybe the best effort is to
modularlize their repo so it can drop on top of (whatever is) the current
version of SC, rather than including their work into SC repo, per se.
Probably there is more than one strategy.

We'd need an effort from the iSCKit team as well, or someone(s) committed
to work on it with their blessing, and presumably starting with that
effort.  They should update their repo to the current version of SC with
a common sense effort to draw clear lines of distinction between platform
specific code and shared code.

Big question is... if someone magically delivered a pull request tomorrow
with a full integration that sustained iSCKit without significant
side-effects to the current version of SC... would this PR be accepted
by sd-dev community?  That is the first step.


Re: Significance of SuperCollider on mobile.  Making SC available as an
option for sound generation on mobile seems to have a natural and
undeniable upside.  SC could influence industry standards.  Not to
mention the technology push and legitimacy SC will get from the gaming
community.

I realize the historic dissonance between a "walled garden" enforced
with digital signatures, managed by a non-transparent corporate entity
versus GPL is formidable.  However, we've demonstrated that there are
no significant violations of GPL v2 by submitting to Apple AppStore.
We have a build hook to enforce GPL v2.  Beyond that, it would be helpful
to document consensus in the SC community --presumably led by core SC
developers-- to submit some form of SC code to the Apple (and other)
app store(s).  Perhaps via a public Memorandum of Understanding.  The
main thing to which Apple is averse is noise from a divided community.
If we are not united on submitting SC into the AppStore, then eventually
they will reject it.  This was roughly the story with VLC.  Other than
that I believe they welcome all forms of software contributions, inclusive
of those that are dynamically self-updating and self-documenting.






Best,
david






        ###

[hidden email] writes on Sun, 4 Feb 2018 21:35:21 -0800:
.
.
. First - there are obstacles to releasing any form of SC actually to the
. store. Second, the approach that would make the most sense would be some
. sort of version of libscsynth.
.
. That all being said, I have made a few apps that send OSC that I can
. then connect to a laptop, etc., I don=E2=80=99t know what I would get
. from an iPad or iPhone that I wouldn=E2=80=99t get from a laptop, so
. I=E2=80=99m not sure what worth a port would even really have (unless it
. was a synth engine I could embed into my own apps - which isn=E2=80=99t
. possible!). So - that all being said - what use case do you see of
. having it work on iPhone? If there is something compelling and you can
. get the rest of the sc-dev community to agree, I=E2=80=99d be more than
. happy to help make it happen. I just don=E2=80=99t know what would
. convince me, at this point, for the effort. Not to put a hammer down or
. anything, I=E2=80=99m just not sure what it would get you.
.
. Best,
.
. Josh
.
.
. > On Feb 4, 2018, at 8:55 PM, [hidden email] wrote:
. >
. > > Would be nice to keep this alive.  I suggest we make an effort to
. > > integrate their repo as a means of minimizing the work necessary to
. keep
. > > the port current as iOS devices and framework generations come and
. go.
. >
. > Of the two repos linked in the paper, this is the only one that still
. exists:
. >
. > https://github.com/wdkk/iSuperColliderKit 
. <https://github.com/wdkk/iSuperColliderKit>
. >
. > It has no commit history in common with the SC repo, no clear summary
. of what's been changed. Looking at Readme.txt it was forked from version
. 3.4. Looking at the commit history, there are new frameworks being
. introduced and diffs of more than 100k LOC per commit. How exactly do
. you propose to integrate this?
. >
. > -Brian
. >
. >
. > On Sun, Feb 4, 2018 at 11:01 PM, <[hidden email]
. <mailto:[hidden email]>> wrote:
. >
. >
. >
. > One of the best ports I have seen comes from Tokyo University of
. > Technology and Watanabe-DENKI, circa 2015:
. >
. >     http://kengolab.net/CreApp/wiki/public/document/isc 
. <http://kengolab.net/CreApp/wiki/public/document/isc>
. >     http://wdkk.co.jp <http://wdkk.co.jp/>
. >
. >
. > See links on kegolab.net <http://kegolab.net/> for GitHub and a paper
. from ICMC 2015:
. >
. >     https://github.com/wdkk/iSuperColliderKit 
. <https://github.com/wdkk/iSuperColliderKit>
. >
. >    
. http://quod.lib.umich.edu/cgi/p/pod/dod-idx/isupercolliderkit-a-toolkit-fo
. r-ios-using-an-internal.pdf?c=icmc;idno=bbp2372.2015.047
. <http://quod.lib.umich.edu/cgi/p/pod/dod-idx/isupercolliderkit-a-toolkit-f
. or-ios-using-an-internal.pdf?c=icmc;idno=bbp2372.2015.047>
. >
. >
. > It is lightweight and flexible.  Offers maximal control over
. SuperCollider
. > with minimal API.
. >
. > Would be nice to keep this alive.  I suggest we make an effort to
. > integrate their repo as a means of minimizing the work necessary to
. keep
. > the port current as iOS devices and framework generations come and go.
. >
. >
. >
. > Best,
. > david
. >
. >
. >
. >
. >
. >         ###
. >
. > [hidden email] <mailto:[hidden email]> writes on Sat, 27 Jan
. 2018 14:11:03 -0800:
. > .
. > . hi folks,
. > .
. > . does supercollider for iphone work anymore? i get the sense that
. it's no
. > . longer really maintained or used.
. > .
. > .
. > . nathan
. > .
. >



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: iphone

brianlheim
> We'd need an effort from the iSCKit team as well, or someone(s) committed
> to work on it with their blessing, and presumably starting with that
> effort.  They should update their repo to the current version of SC with
> a common sense effort to draw clear lines of distinction between platform
> specific code and shared code.

I agree. Until this is done I don't see much of a path for integration. But 3.4 is quite old.

> Re: Significance of SuperCollider on mobile.  Making SC available as an
> option for sound generation on mobile seems to have a natural and
> undeniable upside.  SC could influence industry standards.  Not to
> mention the technology push and legitimacy SC will get from the gaming
> community.

I'm sorry, maybe I'm just dense but I don't see how these things are related at all.

> Big question is... if someone magically delivered a pull request tomorrow
> with a full integration that sustained iSCKit without significant
> side-effects to the current version of SC... would this PR be accepted
> by sd-dev community?  That is the first step.

I don't know. My feeling is, yes, but only if that PR is made with some sort of understand that the original contributor will take part in its maintenance. Realistically speaking there are only so many things we as a project can work on. If it's a one-time contribution that is abandoned or unsupported by the original author, my fear is that it's very likely it will languish and become a burden to active development in other areas. For example, while reworking one of my older PRs I spent a good 5 hours or so making sure old SC_IPHONE code was preserved.

So, I guess the best first step is to reach out to the author of iSCKit and see how they feel about this. I'd be happy to do that.

Regards,

Brian

Reply | Threaded
Open this post in threaded view
|

Re: iphone

dreeder


Hallo Brian, all--


I am wholly sympathatic to your concerns about how an integration like
this is maintained and of being wary about the tail end, all the hidden
costs it may bring.

My work/play ratio is not favorable to working on this at the moment
-- my intent has been to point out this solution and express my enthusiasm
for it.  I realize having done that does afford me no significant
leverage, nor do I want to meddle in something to which I cannot commit
sweat equity.  But who knows... maybe an intrepid champion will be
coaxed from the shadows.

Having said all that...  I agree integration must begin with their repo
syncing up with the current version of SuperCollider.  Meanwhile, it
needs some proposal for which way the integration will go.  Eg: Maybe
it should always be a separate repo, where periodic syncing might be
made easier by agreements about the current structure of SuperCollider,
specifically with regard to platform specific interfaces.  Alternatively,
it goes into a feature branch destined for the next release or the one
after that.  Either solution needs an impact statement and a clear
set of development milestones.


. So, I guess the best first step is to reach out to the author of iSCKit and
. see how they feel about this. I'd be happy to do that.

I think it would be great if you could reach out to them.  If you do
not copy sc-dev, please copy me.

If they have time to respond, and have interest to propose solutions,
maybe that moves this closer to a making this a real project.

      [hidden email]
      [hidden email]
      [hidden email]
      [hidden email]





Best,
david




        ###

[hidden email] writes on Wed, 14 Feb 2018 23:06:45 -0500:
.
. > We'd need an effort from the iSCKit team as well, or someone(s) committed
. > to work on it with their blessing, and presumably starting with that
. > effort.  They should update their repo to the current version of SC with
. > a common sense effort to draw clear lines of distinction between platform
. > specific code and shared code.
.
. I agree. Until this is done I don't see much of a path for integration. But
. 3.4 is quite old.
.
. > Re: Significance of SuperCollider on mobile.  Making SC available as an
. > option for sound generation on mobile seems to have a natural and
. > undeniable upside.  SC could influence industry standards.  Not to
. > mention the technology push and legitimacy SC will get from the gaming
. > community.
.
. I'm sorry, maybe I'm just dense but I don't see how these things are
. related at all.
.
. > Big question is... if someone magically delivered a pull request tomorrow
. > with a full integration that sustained iSCKit without significant
. > side-effects to the current version of SC... would this PR be accepted
. > by sd-dev community?  That is the first step.
.
. I don't know. My feeling is, yes, but *only if* that PR is made with some
. sort of understand that the original contributor will take part in its
. maintenance. Realistically speaking there are only so many things we as a
. project can work on. If it's a one-time contribution that is abandoned or
. unsupported by the original author, my fear is that it's very likely it
. will languish and become a burden to active development in other areas. For
. example, while reworking one of my older PRs I spent a good 5 hours or so
. making sure old SC_IPHONE code was preserved.
.
. So, I guess the best first step is to reach out to the author of iSCKit and
. see how they feel about this. I'd be happy to do that.
.
. Regards,
.
. Brian
.


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/