Page 98 - AC-1-2
P. 98

Arts & Communication                                                          Speculative ubimus design



            parameters. The function sample_pattern_track plays   They feature multiple data types: note, beats, sound,
            a list of samples according to user-defined patterns. The   envelope, envelope_attribute_name, envelope_
            rubato_pattern_track generates events with durations   attribute_value, name, effect, instrument, mode,
            changing gradually, according to three parameters: initial   delay, duration, sample, rest, hit, pattern,
            duration, end duration, and an event/no-event sequence   first, last, and chord_type.
            in xo notation. Choose_play yields random sequences   Beats_per_minute().  The  beats_per_minute()
            based on lists of pitches and durations. Hence, users have   function is used to set the tempo of periodic sequences.
            six complementary strategies at their disposal.    It receives a non-negative integer, from 1 to 900, although
              The sonic results can be used by mixing the tracks as   we expected users to use a value between 60 and 180 for
            synchronous temporal blocks of onsets and durations or   it. If the value is above the threshold, Sonic Pi can throw
            they can be used as sonic resources for manipulation by   a timing exception when playing the track, as the thread
            means  of  third-party  software  (such  as  a  DAW)  to  mix   can get too far behind the time with a high tempo. Box 1
            the independent tracks asynchronously. In other words,   exemplifies its usage.
            Emugel provides support for synchronous live coding but
            it is especially tailored for quasi-synchronous usage.  Box 1. Example of beats_per_minute() function.
              Users write scripts on a sketch file called “user_case.erl”.           beats_per_minute() ->
            The available functions are described in the documentation.              60.
            The Main module starts the program and controls its sonic
            rendition. To generate sound, this module passes the   Pitch-based_track(). The pitch-based_track()
            sketch file name to the Sound_generation module. The   function features pitches and their durations. It is basically a
            Sound_generation module then transfers the sketch file to   list of tuples. Each tuple is a pitch track and includes name,
            the Sonic Pi code and plays the audio. During this process,   mode, duration, delay, instrument, sound,
            the Sonic Pi Tool is used as a bridge between Sonic Pi and   effect, and envelope. Box 2 is an example of its usage.
            Emugel. The generated Sonic Pi code is stored in a cache
            file named “out.rb”. This tool reads the code from the cache   Box 2. An example of pitch-based_track() function.
            file and sends it to the Sonic Pi server. Thus, we avoid the   Name. The name type is defined as a string that labels
            usage of the Sonic Pi’s GUI that would enforce a visual   the track
            approach to the creative tasks (see Lazzarini and Walsh
                                                        [52]
            for an alternative perspective on these issues).     Instrument. The  instrument type  is a string that
                                                               defines the sound source of this track. Since we need to
              The sketch module stores the definitions of the functions
            that handle the sounds. It defines the data structures used   use Sonic Pi, all the instrument strings follow the “synth”
            in the library representing musical elements such as events,   definition of Sonic Pi.
            durations, sound processing tools, synthesis instruments,   Mode. The mode type is related to the generative mode
            and modes. It also specifies the callback functions to   for the track. It can be either loop or non-loop. When the
            implement the music-file modules. Therefore, when users   value is “loop,” the track is iterated till the end of the track
            write their sketches, they need to follow the syntax of these   duration. If the value is 1, the track is played only once. If it
            callback functions (see next section).             is an integer larger than 1, the track is iterated the number
                                                               of times set by the user.
            4.3.1. Lite coding syntax
                                                                 Delay. The delay type can be used to set onset time.
            This section illustrates the data structures of the sketch   It can be either “no_delay” or a positive float number with
            module, including the music elements as well as the   at most three decimal places. If “no_delay” is given, the
            callback functions featured in the sketch files.   track will be played at the sketch onset. If a positive float
            4.3.2. Sketch                                      number is given, the track playing will be delayed by the
                                                               given duration.
            A sonic outcome is abstracted as a “sketch” in our library.
                                                                 Duration. The duration type is used to define the
            A sketch may comprise any of six functions: beats_per_
            minute(), pitch_based_track(), chord_play(),       track duration for a single iteration. As with the  delay
            sample_pattern_track(),       rubato_pattern_      type, when set to “no_duration”, the track will include all
            track(), and choose_play(). These functions can    the events. When a positive float number (three decimal
            be freely combined as independent tracks, supporting as   places) is given, the events will be trimmed to fit with the
            many instances as the device’s memory permits.     given duration.


            Volume 1 Issue 2 (2023)                         9                         https://doi.org/10.36922/ac.1597
   93   94   95   96   97   98   99   100   101   102   103