| Newsgroups |
gmane.comp.audio.supercollider.devel |
| Message-ID |
<[email protected]> |
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
###
[email protected] 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, [email protected] 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, <[email protected]
. <mailto:[email protected]>> 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
. >
. >
. >
. >
. >
. > ###
. >
. > nathan-PB1wun9k+p9Wk0Htik3J/[email protected] <mailto:nathan-PB1wun9k+p9Wk0Htik3J/[email protected]> 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/