Re: iphone

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.

      akinori-9vn4ZAQ/rHchp+bO9/[email protected]
      kengo-xZQif3dyGXjPDbFq/[email protected]
      g3115002e8-9vn4ZAQ/rHchp+bO9/[email protected]
      itoken-NPbm/xcbnpAhp+bO9/[email protected]





Best,
david




	###

[email protected] 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/