Stage 1 complete. Entering stage 2.
8 views
Skip to first unread message
glasto...@googlemail.com
Apr 22, 2010, 3:26:36 PM4/22/10
to supercollider-android-developers
As of now, the SC-A checked in to github is working properly! Wooooo!
Which is to say it goes "ping", we still need to add more features to
make it useful to other people (except people that want to annoy their
dog. It's good at that already). At the end of this mail is a list
of things which I believe SC-A needs to do in order to be cool and
useful. Feel free to delete things, append things, volunteer for
things, or just argue :)
Next Wednesday I'll put it on a wiki page with github Issue numbers
for tasks, and the name of anyone who's working on each task too.
This should make it easy to share if anyone wants to chip in.
Thanks,
Alex
---
1) Be able to start and stop a SuperCollider session using Intents
sent to a Service
This would be a solid, Android-like way to let other apps use us.
Medium-easy to write a service which starts and stops at will. Making
lifetime management stable will be a lot of headache though.
---
2) Be able to receive OSC from another process...
It's our interface onto the world.
2.1) ...via TCP
This will make us compatible with existing SC software, and facilitate
remote use.
Probably fairly easy to call the already-present SC_ComPort code to
serve up sockets onto the server.
2.2) ...via Intents
This will make us friendlier to Android apps. Perhaps we could even
provide a wrapper Java class?
This is more work than 2.1, but we've already got OSCMessages creating
the synth, so it'd be fleshing that code out.
---
3) More UGens
More unit generators means we can support more and exciting
synthesizers.
3.1) Add all the default UGens to the build
We're still not loading all of them
Should be easy to write a script which just hoovers them up into the
Android.mk file
3.2) Have a way for users to install more UGens
This could be fiddly, as you can't keep DLLs in the SD card. To solve
this problem in the past I have put plugins into their own .apk and
used Intents to discover them.
---
4) More synth definitions
Currently, you need to get hold of a default.scsyndef file and dump it
in your sd card before you can hear anything. We should provide a few
synth definitions for people to use, and maybe an intent for adding
them as files.
---
5) Tests
This could be quite fun- what better way to test a synth than to make
something that uses it? Ideally I'd quite like to see some automated
integration tests too, but I'm not going to be a nazi about it until
we've got everything working- we are building on a very stable
foundation.
6) Optimisation
It's a bit crackly at the moment, especially when my mail client kicks
in... I don't think it needs to be- what can we do to optimise?
7) Upstream integration
How best to handle our sources from supercollider.sourceforge? I'd
like to have a little script that you can say "build SC-A against
SuperCollider version <N>" and it does and you can test it.
--
Subscription settings: http://groups.google.com/group/supercollider-android-developers/subscribe?hl=en
Which is to say it goes "ping", we still need to add more features to
make it useful to other people (except people that want to annoy their
dog. It's good at that already). At the end of this mail is a list
of things which I believe SC-A needs to do in order to be cool and
useful. Feel free to delete things, append things, volunteer for
things, or just argue :)
Next Wednesday I'll put it on a wiki page with github Issue numbers
for tasks, and the name of anyone who's working on each task too.
This should make it easy to share if anyone wants to chip in.
Thanks,
Alex
---
1) Be able to start and stop a SuperCollider session using Intents
sent to a Service
This would be a solid, Android-like way to let other apps use us.
Medium-easy to write a service which starts and stops at will. Making
lifetime management stable will be a lot of headache though.
---
2) Be able to receive OSC from another process...
It's our interface onto the world.
2.1) ...via TCP
This will make us compatible with existing SC software, and facilitate
remote use.
Probably fairly easy to call the already-present SC_ComPort code to
serve up sockets onto the server.
2.2) ...via Intents
This will make us friendlier to Android apps. Perhaps we could even
provide a wrapper Java class?
This is more work than 2.1, but we've already got OSCMessages creating
the synth, so it'd be fleshing that code out.
---
3) More UGens
More unit generators means we can support more and exciting
synthesizers.
3.1) Add all the default UGens to the build
We're still not loading all of them
Should be easy to write a script which just hoovers them up into the
Android.mk file
3.2) Have a way for users to install more UGens
This could be fiddly, as you can't keep DLLs in the SD card. To solve
this problem in the past I have put plugins into their own .apk and
used Intents to discover them.
---
4) More synth definitions
Currently, you need to get hold of a default.scsyndef file and dump it
in your sd card before you can hear anything. We should provide a few
synth definitions for people to use, and maybe an intent for adding
them as files.
---
5) Tests
This could be quite fun- what better way to test a synth than to make
something that uses it? Ideally I'd quite like to see some automated
integration tests too, but I'm not going to be a nazi about it until
we've got everything working- we are building on a very stable
foundation.
6) Optimisation
It's a bit crackly at the moment, especially when my mail client kicks
in... I don't think it needs to be- what can we do to optimise?
7) Upstream integration
How best to handle our sources from supercollider.sourceforge? I'd
like to have a little script that you can say "build SC-A against
SuperCollider version <N>" and it does and you can test it.
--
Subscription settings: http://groups.google.com/group/supercollider-android-developers/subscribe?hl=en
Dan Stowell
Apr 23, 2010, 2:18:16 PM4/23/10
to supercollider-an...@googlegroups.com
Congratulations! The hard bit is done! Ha ha :)
Maybe it's worth chatting (IRC or skype perhaps) about plans sometime?
Some comments interspersed:
2010/4/22 glasto...@googlemail.com <glasto...@googlemail.com>:
> 2) Be able to receive OSC from another process...
>
> It's our interface onto the world.
>
> 2.1) ...via TCP
>
> This will make us compatible with existing SC software, and facilitate
> remote use.
>
> Probably fairly easy to call the already-present SC_ComPort code to
> serve up sockets onto the server.
>
> 2.2) ...via Intents
>
> This will make us friendlier to Android apps. Perhaps we could even
> provide a wrapper Java class?
>
> This is more work than 2.1, but we've already got OSCMessages creating
> the synth, so it'd be fleshing that code out.
Well we don't *really* already have OSC messages doing anything since
the C code simply has a make_synth() command which acts as if it was
passing an OSC message in from the real world - so there's no generic
OSC passing happening at the moment.
The route from test program to proper Service with access by TCP
and/or Intents seems to be mainly in designing an AIDL/Intent
interface which provides two-way OSC communication with scsynth. The
protocol is conceptually simple (there are only two types of payload -
message or bundle - and the set of parameter types is small) but
unfortunately quite polymorphic, which doesn't match the
strongly-typed approach needed for AIDL/Intents. So an alternative is
to implement a hook for each of scsynth's commands (there are 63 of
them) to be passed in either direction.
> 3) More UGens
>
> More unit generators means we can support more and exciting
> synthesizers.
Yes!
> 3.1) Add all the default UGens to the build
>
> We're still not loading all of them
>
> Should be easy to write a script which just hoovers them up into the
> Android.mk file
The build file is very repetitive, for all the different plugin libs -
doing it with a script would be fine but it's a shame the Android.mk
file syntax doesn't let us do a simple loop construct.
> 3.2) Have a way for users to install more UGens
>
> This could be fiddly, as you can't keep DLLs in the SD card. To solve
> this problem in the past I have put plugins into their own .apk and
> used Intents to discover them.
Frankly I'd put this as very low-priority. It's an "advanced user"
scenario, and we get advantages if we have a single consistent base of
available ugens. As long as we provide the full core set I don't think
there's much need to do this.
> 4) More synth definitions
>
> Currently, you need to get hold of a default.scsyndef file and dump it
> in your sd card before you can hear anything. We should provide a few
> synth definitions for people to use, and maybe an intent for adding
> them as files.
"an intent for adding" synthdefs should not be needed, since that
should be subsumed under the OSC interface (scsynth can be streamed a
synthdef file by /d_recv or told to load it from the SD card by
/d_load).
Providing synthdefs is a bit tricky cos we can't easily bundle them in
the app, they handle easier if they're on the SD card. Maybe some java
code in the app that copies the basic bunch of synthdef files to SD if
not found?
> 5) Tests
>
> This could be quite fun- what better way to test a synth than to make
> something that uses it? Ideally I'd quite like to see some automated
> integration tests too, but I'm not going to be a nazi about it until
> we've got everything working- we are building on a very stable
> foundation.
There's already a unit-testing scheme but that's sclang-based. I
wonder how straightforward it would be to have scsynth-on-android
controlled by sclang-on-laptop? Obviously that'd be great for many
reasons, but one reason is the unit tests would run straightaway.
> 6) Optimisation
>
> It's a bit crackly at the moment, especially when my mail client kicks
> in... I don't think it needs to be- what can we do to optimise?
Yes, a bit crackly on my lower-spec phone even without other stuff
going on. Optimisation will be the long-haul IMHO, and that's how it
should be - remember the old line about "premature optimisation"...
> 7) Upstream integration
>
> How best to handle our sources from supercollider.sourceforge? I'd
> like to have a little script that you can say "build SC-A against
> SuperCollider version <N>" and it does and you can test it.
We should think carefully about whether to stick with a single SVN
revision or to keep tracking trunk. It can complicate things to keep
updating all the time (I tried to add a plugin source file and got
caught out by an update to a header file). On the other hand, maybe
git has good features for tracking upstream? I haven't used those so
let me know if so. Otherwise, I have no way of knowing which SVN
revision is in git... So unless we have good tracking tools/awareness
it might be helpful to only update from upstream occasionally.
If there's code that needs to go upstream in order to simplify this
then I think we can do that (along similar lines to the iphone code
added in upstream). The native "audio driver" code for android
perhaps.
Dan
Maybe it's worth chatting (IRC or skype perhaps) about plans sometime?
Some comments interspersed:
2010/4/22 glasto...@googlemail.com <glasto...@googlemail.com>:
> As of now, the SC-A checked in to github is working properly! Wooooo!
>
> Which is to say it goes "ping", we still need to add more features to
> make it useful to other people (except people that want to annoy their
> dog. It's good at that already). At the end of this mail is a list
> of things which I believe SC-A needs to do in order to be cool and
> useful. Feel free to delete things, append things, volunteer for
> things, or just argue :)
>
> Next Wednesday I'll put it on a wiki page with github Issue numbers
> for tasks, and the name of anyone who's working on each task too.
> This should make it easy to share if anyone wants to chip in.
>
> Thanks,
>
> Alex
>
> ---
> 1) Be able to start and stop a SuperCollider session using Intents
> sent to a Service
>
> This would be a solid, Android-like way to let other apps use us.
>
> Medium-easy to write a service which starts and stops at will. Making
> lifetime management stable will be a lot of headache though.
Yes, this is critical really.
>
> Which is to say it goes "ping", we still need to add more features to
> make it useful to other people (except people that want to annoy their
> dog. It's good at that already). At the end of this mail is a list
> of things which I believe SC-A needs to do in order to be cool and
> useful. Feel free to delete things, append things, volunteer for
> things, or just argue :)
>
> Next Wednesday I'll put it on a wiki page with github Issue numbers
> for tasks, and the name of anyone who's working on each task too.
> This should make it easy to share if anyone wants to chip in.
>
> Thanks,
>
> Alex
>
> ---
> 1) Be able to start and stop a SuperCollider session using Intents
> sent to a Service
>
> This would be a solid, Android-like way to let other apps use us.
>
> Medium-easy to write a service which starts and stops at will. Making
> lifetime management stable will be a lot of headache though.
> 2) Be able to receive OSC from another process...
>
> It's our interface onto the world.
>
> 2.1) ...via TCP
>
> This will make us compatible with existing SC software, and facilitate
> remote use.
>
> Probably fairly easy to call the already-present SC_ComPort code to
> serve up sockets onto the server.
>
> 2.2) ...via Intents
>
> This will make us friendlier to Android apps. Perhaps we could even
> provide a wrapper Java class?
>
> This is more work than 2.1, but we've already got OSCMessages creating
> the synth, so it'd be fleshing that code out.
the C code simply has a make_synth() command which acts as if it was
passing an OSC message in from the real world - so there's no generic
OSC passing happening at the moment.
The route from test program to proper Service with access by TCP
and/or Intents seems to be mainly in designing an AIDL/Intent
interface which provides two-way OSC communication with scsynth. The
protocol is conceptually simple (there are only two types of payload -
message or bundle - and the set of parameter types is small) but
unfortunately quite polymorphic, which doesn't match the
strongly-typed approach needed for AIDL/Intents. So an alternative is
to implement a hook for each of scsynth's commands (there are 63 of
them) to be passed in either direction.
> 3) More UGens
>
> More unit generators means we can support more and exciting
> synthesizers.
> 3.1) Add all the default UGens to the build
>
> We're still not loading all of them
>
> Should be easy to write a script which just hoovers them up into the
> Android.mk file
doing it with a script would be fine but it's a shame the Android.mk
file syntax doesn't let us do a simple loop construct.
> 3.2) Have a way for users to install more UGens
>
> This could be fiddly, as you can't keep DLLs in the SD card. To solve
> this problem in the past I have put plugins into their own .apk and
> used Intents to discover them.
scenario, and we get advantages if we have a single consistent base of
available ugens. As long as we provide the full core set I don't think
there's much need to do this.
> 4) More synth definitions
>
> Currently, you need to get hold of a default.scsyndef file and dump it
> in your sd card before you can hear anything. We should provide a few
> synth definitions for people to use, and maybe an intent for adding
> them as files.
should be subsumed under the OSC interface (scsynth can be streamed a
synthdef file by /d_recv or told to load it from the SD card by
/d_load).
Providing synthdefs is a bit tricky cos we can't easily bundle them in
the app, they handle easier if they're on the SD card. Maybe some java
code in the app that copies the basic bunch of synthdef files to SD if
not found?
> 5) Tests
>
> This could be quite fun- what better way to test a synth than to make
> something that uses it? Ideally I'd quite like to see some automated
> integration tests too, but I'm not going to be a nazi about it until
> we've got everything working- we are building on a very stable
> foundation.
wonder how straightforward it would be to have scsynth-on-android
controlled by sclang-on-laptop? Obviously that'd be great for many
reasons, but one reason is the unit tests would run straightaway.
> 6) Optimisation
>
> It's a bit crackly at the moment, especially when my mail client kicks
> in... I don't think it needs to be- what can we do to optimise?
going on. Optimisation will be the long-haul IMHO, and that's how it
should be - remember the old line about "premature optimisation"...
> 7) Upstream integration
>
> How best to handle our sources from supercollider.sourceforge? I'd
> like to have a little script that you can say "build SC-A against
> SuperCollider version <N>" and it does and you can test it.
revision or to keep tracking trunk. It can complicate things to keep
updating all the time (I tried to add a plugin source file and got
caught out by an update to a header file). On the other hand, maybe
git has good features for tracking upstream? I haven't used those so
let me know if so. Otherwise, I have no way of knowing which SVN
revision is in git... So unless we have good tracking tools/awareness
it might be helpful to only update from upstream occasionally.
If there's code that needs to go upstream in order to simplify this
then I think we can do that (along similar lines to the iphone code
added in upstream). The native "audio driver" code for android
perhaps.
Dan
glasto...@googlemail.com
Apr 24, 2010, 5:30:28 PM4/24/10
to supercollider-android-developers
Thanks for the comments, IRC sounds good to me. I'm generally around
most school nights and I'll try to remember to be on #superandroid on
irc.imaginarynet.org.uk, anyone reading this who fancies a go at
making supercollidery stuff, pop in for a banter.
Alex
On Apr 23, 7:18 pm, Dan Stowell <danstow...@gmail.com> wrote:
> Congratulations! The hard bit is done! Ha ha :)
>
> Maybe it's worth chatting (IRC or skype perhaps) about plans sometime?
>
> Some comments interspersed:
>
> 2010/4/22 glastonbri...@googlemail.com <glastonbri...@googlemail.com>:
> Subscription settings:http://groups.google.com/group/supercollider-android-developers/subsc...
most school nights and I'll try to remember to be on #superandroid on
irc.imaginarynet.org.uk, anyone reading this who fancies a go at
making supercollidery stuff, pop in for a banter.
Alex
On Apr 23, 7:18 pm, Dan Stowell <danstow...@gmail.com> wrote:
> Congratulations! The hard bit is done! Ha ha :)
>
> Maybe it's worth chatting (IRC or skype perhaps) about plans sometime?
>
> Some comments interspersed:
>
Peter Kirn
Apr 25, 2010, 6:25:05 PM4/25/10
to supercollider-android-developers
I'm curious, do you need *any* app to be able to send intents to the
SC Service, or would you just want to be able to locally bind an
Activity? (I'd guess anything other than the latter would be awfully
advanced, but maybe I'm missing something?)
FYI, I've started up a project for Pd here:
http://code.google.com/p/pdportable/
Let me know if you'd like to join in on that, too.
My interest is the same as yours, though, which is working out a way
to make the Service run reliably. No really usable code there yet,
just a skeleton, but working on it in the next few days. Most of the
issues are the same.
Peter
On Apr 24, 5:30 pm, "glastonbri...@googlemail.com"
SC Service, or would you just want to be able to locally bind an
Activity? (I'd guess anything other than the latter would be awfully
advanced, but maybe I'm missing something?)
FYI, I've started up a project for Pd here:
http://code.google.com/p/pdportable/
Let me know if you'd like to join in on that, too.
My interest is the same as yours, though, which is working out a way
to make the Service run reliably. No really usable code there yet,
just a skeleton, but working on it in the next few days. Most of the
issues are the same.
Peter
On Apr 24, 5:30 pm, "glastonbri...@googlemail.com"
glasto...@googlemail.com
Apr 26, 2010, 4:06:22 AM4/26/10
to supercollider-android-developers
I'm agnostic about binding the service, but I agree it keeps life
simple for now, and if a particular app benefits from having multiple
controllers then it can do the grunt work itself. I'm building a
bluetooth keyboard in my spare^3 time which'd be cool to play along
with supercollider on my phone.
Pd is an equally-compelling project, and I'd be very interested to see
how you're getting along too (there's bound to be opportunities to
share and collaborate). Could you add glastonbridge (at googlemail)
to your Pd list, I'd like to keep a nose in (and maybe even contribute
in my spare^4 time...)
Alex
simple for now, and if a particular app benefits from having multiple
controllers then it can do the grunt work itself. I'm building a
bluetooth keyboard in my spare^3 time which'd be cool to play along
with supercollider on my phone.
Pd is an equally-compelling project, and I'd be very interested to see
how you're getting along too (there's bound to be opportunities to
share and collaborate). Could you add glastonbridge (at googlemail)
to your Pd list, I'd like to keep a nose in (and maybe even contribute
in my spare^4 time...)
Alex
glasto...@googlemail.com
Apr 27, 2010, 4:32:59 PM4/27/10
to supercollider-android-developers
Hey peeps,
I've got some free time tomorrow, I'm going to take a pop at splitting
the existing code into a Service and an Activity (Issue #6).
http://github.com/glastonbridge/SuperCollider-Android/issues/labels/Stage%202%20Roadmap
From now on, if you're working on something, say so on there first and
we can avoid clashing code. I reckon if we close those four off we
can take a break and write some toys that actually use it!
Alex
On Apr 26, 9:06 am, "glastonbri...@googlemail.com"
I've got some free time tomorrow, I'm going to take a pop at splitting
the existing code into a Service and an Activity (Issue #6).
http://github.com/glastonbridge/SuperCollider-Android/issues/labels/Stage%202%20Roadmap
From now on, if you're working on something, say so on there first and
we can avoid clashing code. I reckon if we close those four off we
can take a break and write some toys that actually use it!
Alex
On Apr 26, 9:06 am, "glastonbri...@googlemail.com"
Peter Kirn
Apr 27, 2010, 5:49:21 PM4/27/10
to supercollider-android-developers
Actually, if you want, Alex, that portion should be pretty identical
in SuperCollider and Pd. The one difference is, I didn't set it up to
bind to anything other than the parent Activity, but you could easily
add that to my existing framework.
That portion is pushed here; it's actually the Pd-specific JNI native
code we're working out.
http://code.google.com/p/pdportable/
One thing I have not done yet, as well, is to do the backwards-
compatible wrapping that would allow this to run on pre-2.x devices. I
do intend to do that and test accordingly, though, once we get the
other portions working.
The main thing is to set foreground priority properly and start and
stop the service. So it may be helpful... though it is mainly based on
the standard API examples, nothing unusual.
Peter
On Apr 27, 4:32 pm, "glastonbri...@googlemail.com"
in SuperCollider and Pd. The one difference is, I didn't set it up to
bind to anything other than the parent Activity, but you could easily
add that to my existing framework.
That portion is pushed here; it's actually the Pd-specific JNI native
code we're working out.
http://code.google.com/p/pdportable/
One thing I have not done yet, as well, is to do the backwards-
compatible wrapping that would allow this to run on pre-2.x devices. I
do intend to do that and test accordingly, though, once we get the
other portions working.
The main thing is to set foreground priority properly and start and
stop the service. So it may be helpful... though it is mainly based on
the standard API examples, nothing unusual.
Peter
On Apr 27, 4:32 pm, "glastonbri...@googlemail.com"
<glastonbri...@googlemail.com> wrote:
> Hey peeps,
>
> I've got some free time tomorrow, I'm going to take a pop at splitting
> the existing code into a Service and an Activity (Issue #6).
>
> http://github.com/glastonbridge/SuperCollider-Android/issues/labels/S...
> Hey peeps,
>
> I've got some free time tomorrow, I'm going to take a pop at splitting
> the existing code into a Service and an Activity (Issue #6).
>
glasto...@googlemail.com
Apr 27, 2010, 6:05:12 PM4/27/10
to supercollider-android-developers
OOH! Smart! Thanks, Peter. I shall repay your kindness by doing the
backwards compatible wrapping- my weapon of choice is still a 1.6 HTC
Magic :) What features are missing in earlier versions of Android?
Alex
On Apr 27, 10:49 pm, Peter Kirn <peterk...@gmail.com> wrote:
> Actually, if you want, Alex, that portion should be pretty identical
> in SuperCollider and Pd. The one difference is, I didn't set it up to
> bind to anything other than the parent Activity, but you could easily
> add that to my existing framework.
>
> That portion is pushed here; it's actually the Pd-specific JNI native
> code we're working out.http://code.google.com/p/pdportable/
> ...
>
> read more »
backwards compatible wrapping- my weapon of choice is still a 1.6 HTC
Magic :) What features are missing in earlier versions of Android?
Alex
On Apr 27, 10:49 pm, Peter Kirn <peterk...@gmail.com> wrote:
> Actually, if you want, Alex, that portion should be pretty identical
> in SuperCollider and Pd. The one difference is, I didn't set it up to
> bind to anything other than the parent Activity, but you could easily
> add that to my existing framework.
>
> That portion is pushed here; it's actually the Pd-specific JNI native
>
> read more »
Peter Kirn
Apr 27, 2010, 9:56:30 PM4/27/10
to supercollider-android-developers
Credit where it's due -- Naim Falandino is adding a whole bunch of
stuff to that repo; getting a lot better.
On Apr 27, 6:05 pm, "glastonbri...@googlemail.com"
> ...
>
> read more »
stuff to that repo; getting a lot better.
On Apr 27, 6:05 pm, "glastonbri...@googlemail.com"
>
> read more »
Peter Kirn
Apr 27, 2010, 10:01:55 PM4/27/10
to supercollider-android-developers
Here you go...
Check out com.example.android.apis.app.ForegroundService. You'll see I
did some radical simplification temporarily which I intend to bring
back. I'll go ahead and do that, actually, in the next push, probably
tomorrow.
Peter
> ...
>
> read more »
Check out com.example.android.apis.app.ForegroundService. You'll see I
did some radical simplification temporarily which I intend to bring
back. I'll go ahead and do that, actually, in the next push, probably
tomorrow.
Peter
>
> read more »
Alex
May 2, 2010, 6:53:23 PM5/2/10
to supercollider-android-developers
Ah! Now I understand why you were wondering about binding- I've never
written a bound Service before and didn't realise how the IDL worked,
it's quite neat. It's up and running now, though the foreground
service bit is now optional which allows it to run on my Magic. It
seems that earlier Androids call onStart and later ones call
onStartCommand, so you can switch the ForegroundService stuff from
there.
http://github.com/glastonbridge/SuperCollider-Android/blob/master/src/uk/co/mcld/dabble/GlastoCollider1/ScService.java
So yeah, SuperCollider-Android has a Service and it works! Thanks too
to Dan, I see you've done some puts this week (and I especially like
the new screen :) ). Once we've got some OSC working, I think it'll
look pretty impressive!
Alex
> ...
>
> read more »
written a bound Service before and didn't realise how the IDL worked,
it's quite neat. It's up and running now, though the foreground
service bit is now optional which allows it to run on my Magic. It
seems that earlier Androids call onStart and later ones call
onStartCommand, so you can switch the ForegroundService stuff from
there.
http://github.com/glastonbridge/SuperCollider-Android/blob/master/src/uk/co/mcld/dabble/GlastoCollider1/ScService.java
So yeah, SuperCollider-Android has a Service and it works! Thanks too
to Dan, I see you've done some puts this week (and I especially like
the new screen :) ). Once we've got some OSC working, I think it'll
look pretty impressive!
Alex
>
> read more »
Reply all
Reply to author
Forward
0 new messages