[Stk] Fwd: Improving support for iOS

Gary Scavone gary at ccrma.Stanford.EDU
Thu Sep 12 06:59:10 PDT 2013 

It would be very difficult to express the controls in physical units.  First of all, not all algorithms are physics-based models.  But even the physical models are generally not developed with respect to exact physical measurements and/or quantities.  There is also a trend in the modeling world to use dimensionless control parameters.

--gary

On 2013-09-12, at 9:48 AM, Jeremy Jurksztowicz <jurksztowicz at gmail.com> wrote:

> Bjarne Stroustrup recently demoed how to properly do units in modern
> C++. It would take quite a lot of work, but seems like it would be
> very useful for physical modelling. I'm sure that game developers and
> others who are not so interested in musical properties would find this
> very helpful.
> 
> On Thu, Sep 12, 2013 at 8:49 AM, Stephen Sinclair
> <sinclair at music.mcgill.ca> wrote:
>> 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
>>> 
>> 
>> _______________________________________________
>> 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

More information about the Stk mailing list