[Stk] Fwd: Improving support for iOS

Thu Sep 12 05:49:46 PDT 2013

Hi,

Personally, I think if controlChange() were ever to be refactored, the
most desirable approach would be for Instrument-specific controls to
be expressed in physically meaningful units.  E.g., breath pressure in
Pa, bowing velocity in m/s, etc.

A SKINI/MIDI conversion layer on top of this would be appropriate, but
for research purposes it can be very useful to express things
physically instead of on a normalized scale from 0 to 127.

I realize this would represent quite a bit of work, however.

Steve

On Wed, Sep 11, 2013 at 7:48 PM, Perry Cook <prc at cs.princeton.edu> wrote:
> Another one that should go to the list.
>
> Good comments from a loyal STK user.
>
>
> Sent from my iPad :-)
>
> Begin forwarded message:
>
> From: Michael Gogins <michael.gogins at gmail.com>
> Date: September 11, 2013, 10:43:55 AM PDT
> To: Perry Cook <prc at CS.Princeton.EDU>
> Subject: Re: [Stk] Improving support for iOS
>
> I'm a constant user of the STK for my compositions (and author of a thin
> wrapper template class that gets all the STK instruments into Csound).
>
> Please excuse me in the following for mentioning many things that you
> undoubtedly have already thought of.
>
> I hope that whatever strategy you use for dealing with the SKINI business
> will keep all the STK classes using a common protocol for control changes.
>
> One pattern widely used for this sort of thing is to factor the protocol
> into two layers. The bottom layer would be constant for all users. The top
> layer would one thing for SKINI, another for MIDI, and so on.
>
> A facade could be used to wrap the bottom layer (including the STK
> instruments and effects themselves) to be used for various top layer
> protocols...
>
> Such a facade, a template adapter class, is what Csound uses to get control
> messages from the Csound score language into the STK instrument and effect
> classes. It would be possible to write a similar template adapter class for
> MIDI, for SKINI, for OSC, for MusicXML, for Fomus, etc.
>
> These layers could have factories that might dynamically load actual drivers
> that could differ by protocol and by platform, so that code need not be
> compiled as part of the STK itself or statically linked with it.
>
> Or, perhaps better yet and more in keeping with the existing admirable STK
> "lighter is better" philosophy, the drivers could be header-file-only code
> with platform #ifdefs and static function factories for managing any static
> data.
>
> It's surprising how many developers don't use header-file-only libraries,
> which have many advantages. Boost does though... Eigen does...
>
> Regards,
> Mike Gogins
>
> Regards,
> Mike
>
>
> ===========================
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Sep 11, 2013 at 12:58 PM, Perry Cook <prc at cs.princeton.edu> wrote:
>>
>> Re-posting this to the list:
>>
>> Ari:  I love your work, apps, and enthusiasm for STK!!!
>>
>> I would totally support any re factorization of STK that makes it
>> more useable and more modular.  I myself have tried to use just
>> a class or two and found I had to play a "Whack-a-Mole" game of
>> #includes and errors.  And Git would be wonderful too.
>>
>> My thoughts on control changes and SKINI:
>>
>> How about a simple #define SKINI
>> combined with ifdefs placed in the right places?
>> That way any classes could be used and modified
>> alone (or with the appropriate small number of
>> dependencies), but they wouldn't look for or complain
>> about missing SKINI.
>>
>> It's possible that other dependencies necessary for the full
>> demo version of STK, but not required for putting together
>> small projects, could be similarly dealt with by adding some
>> #defines and #ifdefs?
>>
>> My thoughts on first blush.
>>
>> Prc
>>
>> Sent from my iPad :-)
>>
>> On Sep 10, 2013, at 6:41 AM, Gary Scavone <gary at ccrma.Stanford.EDU> wrote:
>>
>> > Dear Ariel,
>> >
>> > Thanks for your suggestions, enthusiasm, and offer to help!  Your email
>> > is timely because it is becoming harder and harder for me to find the time
>> > to properly support STK (and RtAudio and RtMidi).  So, I agree that STK
>> > should go into GitHub.  I don't have prior experience starting a GitHub
>> > project … are there any particular things I should pay attention to?
>> >
>> > I agree with most of your suggestions, though I'd like to hear Perry's
>> > opinion about SKINI.  I think the controlChange function is useful because
>> > it shows how one would go about using the various class-specific parameter
>> > update functions, as well as providing a simple, common function to
>> > experiment with the various Instrmnt classes.  If we took out the
>> > controlChange function, many of the current demos would cease to work.  And
>> > if we hose SKINI, we'd still need to use some sort of control scheme.
>> >
>> > Another thing that needs to happen is that RtAudio and RtMidi need to be
>> > extracted to separate GitHub projects, as there are many people that want to
>> > build those as shared libraries and not have redundant versions in the STK
>> > folder.  Then we need to find a way to allow them to be easily used within
>> > STK without necessarily bundling them in STK.
>> >
>> > --gary
>> >
>> > On 2013-09-10, at 8:51 AM, Ariel Elkin <arielelkin at gmail.com> wrote:
>> >
>> >> The STK is one of the most useful open-source libraries available for
>> >> audio synthesis and processing. One of its aims is cross-platform
>> >> functionality, and one of the platforms where it's had a lot of success is
>> >> iOS. Ever since MoMu-STK, many iPhone and iPad apps based on the STK have
>> >> seen the day (I myself have used the STK in four of the apps I've released
>> >> or helped release on the App Store). And the number of iOS developers
>> >> requiring or just interested in audio synthesis on iPhones and iPads is
>> >> large and expanding.
>> >>
>> >> The field of mobile music music-making is worthwhile and expanding, and
>> >> iOS being one of the platforms of choice, the STK's should fully support it.
>> >>
>> >> There's specific interest in the STK for iOS. I've had over 5,000
>> >> unique visitors on the STK tutorial I wrote for iOS:
>> >> http://arivibes.com/realtime-audio-on-ios-tutorial-making-a-mandolin/
>> >> And people regularly email me asking for more tutorials.
>> >>
>> >> But the STK's current support for iOS is below par. Although iOS can
>> >> speak C++, the Toolkit has some design attributes that make it incompatible
>> >> with iOS. If an iOS developer drags and drops the current STK release
>> >> (v4.4.4) into Xcode, dozens and dozens of build errors start stemming from
>> >> the STK classes. Fixing them is unfortunately not a trivial task.
>> >>
>> >> There's the possibility of using MoMu-STK, but that ported v4.4.2. The
>> >> MoMu project is ostensibly no longer maintained (the only version released
>> >> was in 2009), so the bug fixes and new STK classes that came with later
>> >> versions aren't included. Additionally, MoMu-STK generates something like 80
>> >> compiler warnings. MoMu-STK is not really a good alternative.
>> >>
>> >> So let's improve the STK's support for iOS. I thought of several
>> >> enhancements that would improve the STK's support for iOS, AND make it
>> >> easier to create ports for other platforms:
>> >>
>> >>
>> >> A) GROUP AUDIO CLASSES SEPARATELY
>> >> Clearly separate the STK's audio classes from the STK's helper classes.
>> >> Classes solely dedicated to audio purposes (e.g. Sitar, PRCRev, etc.) should
>> >> be grouped in their directory. The STK's helper classes, such as those for
>> >> networking (e.g. Socket, TcpClient) multithreading (e.g. Mutex), or audio
>> >> layer setup (e.g. RtAudio), should be in separate directories.
>> >>
>> >> STK users should be able to easily select and drag and drop just the
>> >> strictly necessary audio classes. This is because platforms such as iOS
>> >> already provide APIs that effectively supersede the STK's helper classes.
>> >>
>> >>
>> >> B) DON'T MAKE AUDIO CLASSES DEPEND ON SKINI
>> >> The STK's audio classes (the Instruments in particular, such as
>> >> Clarinet, Flute, Moog, etc.) should no longer be dependent on SKINI
>> >> (Synthesis toolKit Instrument Network Interface). The SKINI protocol is a
>> >> venerable instrument controller system, but nowadays many STK users are more
>> >> likely to write their own control change functions using the STK
>> >> Instruments' current functions. The STK's Instruments' controlChange()
>> >> function is thus redundant to a lot of users.
>> >>
>> >> Ideally, get rid of SKINI and controlChange() functions altogether. If
>> >> the STK's Instruments MUST keep their controlChange() function, then don't
>> >> force users to import SKINI every time they want to use an STK class!
>> >>
>> >>
>> >> C) DEFINE MACROS FOR IPHONE
>> >> Add a #define macro for __OS_IPHONE__ at the bottom of Stk.h. This may
>> >> come in very handy in later updates to the Toolkit, and will at least allow
>> >> a clean way to fix the rawwaves directory.
>> >>
>> >>
>> >> D) EXAMPLE PROJECTS
>> >> Add example projects that show how to use the STK using the latest
>> >> IDEs. Include an example project for iOS that uses Xcode 4!
>> >>
>> >>
>> >> E) GITHUB
>> >> Put the STK on GitHub! Give us a good reason not to? Putting the the
>> >> STK on GitHub will increase its visibility, facilitate the release of quick
>> >> fixes, and attract code contributions from other developers. It's easy and
>> >> free.
>> >>
>> >>
>> >>
>> >>
>> >> I have been working on an Xcode project that illustrates some necessary
>> >> steps to modify the current STK to get it to work on iOS:
>> >> https://github.com/arielelkin/STK-on-iOS
>> >>
>> >> You can see more details in its commit history. But I don't really want
>> >> that repository to become a *port* of the STK. The big disadvantage of
>> >> making a port is clear: every time there'll be an update of the STK, the
>> >> update will have to be manually merged into the port! I see the above Xcode
>> >> project as a transitory thing, the idea behind it is to help integrate those
>> >> changes INTO the STK so that it fully supports iOS.
>> >>
>> >> I'd be happy to give a hand with this.
>> >>
>> >>
>> >> Dear maintainers of the STK (Gary, Stephen, Perry), dear users of the
>> >> STK, what are your thoughts?
>> >>
>> >>
>> >> Cheers,
>> >> Ariel
>> >
>>
>> _______________________________________________
>> Stk mailing list
>> Stk at ccrma.stanford.edu
>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>
>
>
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>