MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Reactive-banana",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "4235": {
                "pageid": 4235,
                "ns": 0,
                "title": "Reactive",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "[[Category:FRP]]\n[[Category:Packages]]\n\n== Abstract ==\n\n'''Reactive''' is a simple foundation for [[Functional Reactive Programming|programming reactive systems functionally]].  Like [http://conal.net/Fran/ Fran]/FRP, Reactive has a notions of (reactive) behaviors and events.  Some unusual features:\n* Much of the original interface is replaced by instances of standard type classes.  In most cases, the denotational semantics of these instances is simple and inevitable, following from the principle of [http://conal.net/blog/posts/simplifying-semantics-with-type-class-morphisms/ type class morphisms].\n* The original idea of reactive behaviors is composed out of two simple notions:\n**  ''Reactive values'' are temporally discrete and reactive.  They have a purely data representation, and so cache for free.\n**  ''Time functions'' are temporally continuous and non-reactive.\n* Reactive provides and builds on ''functional futures'', which are time/value pairs with several handy type class instances.  Futures allow one to conveniently compute with values before they can be known, with a simple, purely functional semantics (no IO).  Futures are polymorphic over both values ''and'' time, requiring only that time is ordered.\n* A particularly useful type of time, based on Warren Burton's ''improving values'', reveals partial information in the form of lower bounds and minima, before the times can be known precisely.  (Semantically non-flat.)\n* Improving values are implemented on top of a semantically simple ''unambiguous choice'' operator, [[unamb]].  Although unamb is built on [[GHC/Concurrency|Concurrent Haskell]] threads, the scheduler nondeterminism does not leak through (assuming the argument-compatibility precondition holds).\n* Reactive manages (I hope) to get the efficiency of data-driven computation with a (sort-of) demand-driven architecture.  For that reason, Reactive is garbage-collector-friendly. ([[DataDriven#GC_favors_demand-driven_computation|GC favors demand-driven computation]].)\n\n\nThe inspiration for Reactive was Mike Sperber's [http://www-pu.informatik.uni-tuebingen.de/lula/deutsch/publications.html Lula] implementation of FRP.  Mike used blocking threads, which I had never considered for FRP before a conversation with him at ICFP 2007.  While playing with the idea, I realized that I could give a very elegant and efficient solution to caching.\n\nBesides this wiki page, here are more ways to find out about and get involved with Reactive:\n* Check out the series of Reactive tutorial posts beginning with ''[http://netsuperbrain.com/blog/posts/introducing-reactive-events/ Introducing Reactive: Events]''.\n* Contribute a tutorial to [[Reactive/Tutorials]]\n* Read the paper ''[http://conal.net/papers/simply-reactive/ Simply Efficient Functional Reactivity]'' and its [http://conal.net/blog/posts/simply-efficient-functional-reactivity/ blog post with discussion].\n* Join the [http://www.haskell.org/mailman/listinfo/reactive Reactive mailing list].\n* Visit the [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/reactive Hackage page] for library documentation and to download & install.\n* Or install with <tt>cabal install reactive</tt>.\n* Download the code repository: '''<tt>darcs get http://code.haskell.org/reactive/</tt>'''.  Patches welcome.\n* Report bugs and request features on [http://trac.haskell.org/reactive/ the tracker].\n<!-- * Examine the [[Reactive/Versions| version history]]. -->\n\nReactive is intended to be used with a variety of \"legacy\" (imperative) libraries for graphics, GUI, robotics, web services, automatic recompilation and re-execution, etc.  For an example of how to wrap up such libraries for use with Reactive, see the [[reactive-glut]] project.\n\nThe [[reactive-fieldtrip]] project connects Reactive and [[FieldTrip]].\n\n\nThis page replaces [[old-reactive]]."
                    }
                ]
            },
            "7963": {
                "pageid": 7963,
                "ns": 0,
                "title": "Reactive-balsa",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "'''Reactive-balsa''' is a live [[MIDI]] event processor based on the [[Reactive-banana]] framework and [[ALSA]]. (Thus it is currently bound to Linux.) It is the successor of the package [[StreamEd]], that uses a kind of arrow types.\n\nThe MIDI event processor can be used for accompaniment, gags, games and more. It is usually inserted between a MIDI input device such as a USB piano keyboard and a MIDI controlled synthesizer, say an internal software [[synthesizer]] or an external hardware synthesizer.\n\nSome of the included examples:\n\n* split keyboard\n* transposition\n* delay\n* map key to filter frequency\n* arpeggiator: play a pattern according to pressed keys\n* generate a beat with controllable tempo\n* instrument cycling: every note is played with a different instrument\n* LFO-controlled change of MIDI controllers\n* simulate playing chords on a guitar\n* interval recognition trainer\n* keyboard with mirrored order of keys: perfect support for lefties :-)\n\nThe functional reactive programming paradigm has precisely the right abstractions that we need for MIDI event processing:\n\n* Events are discrete MIDI events for key press and release, knob turning and fader move, instrument change,\n* Behaviours are things like current position of a knob or fader or the set of currently pressed keys.\n\nThis becomes especially useful for the arpeggiator. There are several ways to obtain a set of keys:\n\n* The actual set of pressed keys.\n* Latched keys: Every key press toggles between press and release\n* Group latched keys: A chord is hold until a new chord is played.\n* Serial latch: A queue of fixed length holds pressed keys. Newly pressed keys release old keys.\n\nAnd there are many ways to generate MIDI events from a set of keys:\n\n* cycle them up or down, or play them in ping-pong mode,\n* play them randomly,\n* play algorithmic patterns, like de-Bruijn sequences or k-nary cross sums, Gray codes or Johnson-Trotter-permutations,\n* play the set of keys with random inversions.\n\n\nThe reactive-banana framework enforces the distinction between processes that react only to input events (like reversed keyboard, split keyboard, transposition) and processes that can generate events by themselves (like beat generator, LFO). The first kind of processes is represented by non-monadic functions, whereas the second kind needs to run in the <hask>NetworkDescription</hask> monad. It turns out that this distinction is useful when it comes to MIDI controlled switches between MIDI processors: There is a canonical way to suspend and resume the first kind of processes, they do not need computations while at rest. For the second kind of processes there are multiple ways how to treat them when suspended.\n\n\n{{PackageInfoBox|name=reactive-balsa|darcs-code=~thielema/reactive-balsa/}}\n\n[[Category:Music]]"
                    }
                ]
            }
        }
    }
}