zmidi-basic

Copperbox revision 2677.

I've added sequential concatenation for events - play one after the other.

zmidi-basic

Copperbox revision 2676.

I've changed zmidi-basic so it uses an event representation - MIDI events like NoteOn at some point in time - rather than a symbolic representation - notes, rests, chords. This is quite a turn around as I've previously loathed MIDI's control representation, but... a control representation is very flexible and it is very easy to build a symbolic representation on top of a control representation whereas the reverse is impossible [*].

[*] Realizing this was a giant - d'oh I've been on the wrong path for years - moment.

zmidi-core

Copperbox revision 2675.

I've added an example that generates MIDI, the existing examples processed MIDI files.

The AST exposed by ZMidi-Core is to low level for generating MIDI directly, but this example shows how it works.

new-neume

Copperbox revision 2674.

I've changed the Score and NoteList monad so they are newtype wrappers over the same monad - they need to be newtypes because they have different Doc representations (and different concatenation).

This has unified the code quite a bit, though it still needs tidying up and repeat voltas need re-implementing.

wumpus

Copperbox revision 2673.

Work on symbols in Wumpus-Drawing and minor modifications to Wumpus_Basic (corrected a doc error, changes to Chain to make the chain schemes follow a naming convention).

wumpus

Copperbox revision 2672.

I've updated Wumpus-Rhythm and Wumpus-Tree so that the Haddock docs build again.

wumpus-drawing

Copperbox revision 2671.

I've updated the examples to compile again. Some of them probably hadn't been working for a long time.

wumpus

Copperbox revision 2670.

I've updated the Chain API in Wumpus-Basic and modified the Axes module in Wumpus-Drawing to match the changes. There may be some demos that need updating...

wumpus-basic

Copperbox revision 2669.

Initial work updating the Chain module. I've removed the setSchemeScheme function and added a counting chain scheme builder instead. The API will need some thinking about - particular as there isn't actually much you can currently do in the Chain monad...

wumpus-drawing

Copperbox revision 2668.

Updated to work with the change from ZDeco to ZOrder in Wumpus-Basic.

wumpus-basic

Copperbox revision 2667.

I've renamed the ZDeco enum to ZOrder and changed the names of the constructors.

Hiatus - I haven't made any commits for a week as I was working on FMSS but produced nothing satisfactory. Probably I should punt FMSS and PDSS into the long grass.

jerry-osc

Copperbox revision 2666.

I've added support for blobs and bundles and improved the code a bit. Time stamps still need implementing properly.

joinlist

Copperbox revision 2665.

First bit of work updating the Join List data type. I've drop the two "silly" functions and made some of the internal names more idiomatic.

data-aviary

Copperbox revision 2664.

I've tidied up data-aviary so it is explicit that is is intended for illustration rather than use.

Before the end of the the year, I should probably tidy up my projects on Hackage or ask for them to be hidden in the index.

jerry-osc

Copperbox revision 2663.

I've added a UDP sever to listen to OSC messages from Pd.

jerry-osc

Copperbox revision 2662.

I've started a new library jerry-osc for packing and unpacking OSC (Open Sound Control) messages. There is already a library to do this on Hackage but it is too big for my needs. Also, I want to get a handle on the OSC protocol and writing my own library is one way to do this.

The name implies that it is jerry built.

PDSS has ground to a halt, hence commits to Copperbox halted last week. The design of PDSS had taken a wrong turn - as it grew, it was embedding Pd as a language. This is usually a bad strategy, successful generative DSLs like Pan usually embed a model that target language code can be generated from, rather than embed the target language as manipulatable syntax. After next week I'll have more time for coding, so I'll look to only generating FM synthesizers as per FMSS.

pdss

Copperbox revision 2661.

I've added some more Glue objects - select, route and pack. This has highlighted some things I've overlooked like types in Pd and "function" arities.

pdss

Copperbox revision 2660.

More work typing ports, plus I've added bounding box calculation for float and symbol atoms.

With the changes to ports, I've also added a simpler constructor for objects so now all objects in libraries like Glue and Math should be two-liners - one line for the type signature and one of the function definition.

pdss

Copperbox revision 2559.

I've changed the object representation to used sized types to count the number of ports - this will cut down quite a bit of boilerplate.

pdss

Copperbox revision 2658.

A bit more work replacing Bool flags with enumerated types.

pdss

Copperbox revision 2657.

I've replaced so uses of Bool in function argument lists with more descriptive enumerated types.

This will also make things clearer if I need to add them to the context so I can have default values.

pdss

Copperbox revision 2656.

I've added a canvas object (unfortunately Pd calls two different things canvas).

Most of the Pd objects are now tentatively implemented, I'll have to work out what to do with them...

pdss

Copperbox revision 2655.

I've added vertical and horizontal slider objects, and implemented bounding box calculation for the messages.

pdss

Copperbox revision 2654.

I've improved some more objects by adding properly calculated bounding boxes.

pdss

Copperbox revision 2653.

I've added a correct (contextual) bounding box to some of the simple objects (print and int) and started to put object definitions into libraries to match the Pd layout - only Glue so far and only a few members of it...

Embedding Pd will have a lot of name clashes with Haskell's Prelude that I will have to do something about.

pdss

Copperbox revision 2652.

Initial work on calculating bounding boxes. I've worked out the sizes of objects boxes - this required counting the pixels which was a bit laborious, but at least I've worked out an algorithm for it.

pdss

Copperbox revision 2651.

I've decided the generic object wasn't a good idea so I've removed it. Also added a few more objects.

pdss

Copperbox revision 2650.

More work on objects.

Many objects are generic and are just drawn with a box and its ports (print, integer literals, random etc.). I'm not sure if these are worth the boilerplate of a newtype for every object, so for the time being I've added a generic object so I can avoid the newtype wrapping.

pdss

Copperbox revision 2649.

I've added label offsets to the Context as a number of objects need them. Added a toggle object.

pdss

Copperbox revision 2648.

I've added a lot of abstractions from Wumpus and now PDSS can generate working Pd patches:

pdss

Copperbox revision 2647.

I've added PdContext to monad - the PdContext will work like the DrawingContext in Wumpus-Basic so objects like canvas can take graphic parameters like fill colour, font etc. from the implicit context rather than need them supplied as arguments to the constructor.

PDSS will probably get quite a bit of the functionality of Wumpus-Basic, so pdss-core won't be directly analogue to Wumpus-Core.

pdss

Copperbox revision 2646.

More work on the Doc builders.

This code is easy to do without thinking about it, hopefully I should be able to tackle something more ambitious tomorrow as it's the weekend.

pdss

Copperbox revision 2645.

I've tidied up the Colour code and the Doc code so it should be more readable. Particularly, the code has been formatted so it is easier to count the arguments supplied to records - PD doesn't reject files with bad record arities, instead they lead to obscure bugs. 

pdss

Copperbox revision 2644.

Finally I've got working RGB colours. The code needs tidying up, but I wanted to commit it now while it works (I don't what to lose the working coding tidying it up...).

pdss

Copperbox revision 2643.

More work on colour handling - still buggy, but somewhat nearer. The PD file format reference on the web is wrong, colours are 18-bit in PD. There are a couple of descriptions of a formula to convert to 18-bit on the web but I haven't got one working yet. I actually had a bigger problem where I was generating the wrong argument list for cnv objects.

pdss

Copperbox revision 2642.

Work on RGB colour, which is currently buggy as I can't fathom the conversion formula given in the guide to the PD file format.

pdss

Copperbox revision 2641.

I've expanded PDSS so the internals follow the example of Wumpus-Core. A number of abstractions in Wumpus are going to be pertinent to PDSS, so adopting the module layout of Wumpus-Core seems wise.

pdss

Copperbox revision 2640.

I've added the Format Combinators from Wumpus rather than depend on PrettyPJ.

Wumpus-Basic exposes the Format Combinators which seems wrong now I think about it.

pdss

Copperbox revision 2639.

I've started a new project PDSS - this intends to be an analogue to FMSS but it generates PD code rather than Csound.

new-neume

Copperbox revision 2638.

I've changed the Concat combinators to use re-defined versions the regular pretty print names. This makes the example look like they are just pretty printing even though they are implemented with a monad.

new-neume

Copperbox revision 2637.

Work on the Bulgarian 6 example - the first four bars now print.

new-neume

Copperbox revision 2636.

More work adding pretty printers for LilyPond syntax elements.

new-neume

Copperbox revision 2635.

I've added explicit combinators for monadic concatenation-with-spacing rather than use Conal Elliott's context monoid pattern implicitly within the Score and Note List monads.

new-neume

Copperbox revision 2634.

I've now added proper relative blocks to the score language.

new-neume

Copperbox revision 2633.

I've sorted out the nested monads and added chords and rests.

new-neume

Copperbox revision 2632.

I've added a monad for top level scores, this will get a run function for the note list monad so it can accumulate its results. This means Neume will follow the nested monad pattern that I used for FMSS (FM synthesizer synthesizer) in the summer.

new-neume

Copperbox revision 2631.

I've added preliminary support for beam grouping. This has forced a change of representation as beam groups in LilyPond don't enclose the whole group instead the first note of the group is outside the bracket. e.g a [c d e]

new-neume

Copperbox revision 2630.

I've extended the LilyPond monad so it can handle printing absolute or relative pitches. In the old version of Neume, this was a transformation mapped over the input notelist. In the new version this is a change to the rendering environment cf. local in the Reader monad.

Note - not enough code is in place at the moment to actually demonstrate the above.

neume

Copperbox revision 2629.

I've started a new revision of Neume - I was going to wait until I had more time at the Christmas holidays to do this but I got itchy feet...

Instead of building a syntax tree, transforming it and printing it; I'm going to see if I can use only monadic building (no transformation). This means that you have to be very cognisant of what you are building (you can easily build junk) but it may be less brittle than previous versions which struggled to cope with LilyPond's wild syntax. LilyPond's syntax is not at fault - music notation has had a thousand years to develop a truly unwieldy grammar.

wumpus-basic

Copperbox revision 2628.

I've now removed the Wumpus.Basic.Geometry modules.

In a nutshell, I don't want to be in the business of developing a geometry kernel - when I need geometric operations I can define them where they are used (as I'm doing now in Wumpus-Drawing). Also, the actual code in Basic.Geometry was often of a low standard - not providing such code as a public API is sensible.

wumpus-drawing

Copperbox revision 2627.

I've removed the last dependency on Wumpus.Basic.Geomoetry - from the anchor dots.

Note - Anchor dots will need reworking at some point as they aren't very good.

wumpus-drawing

Copperbox revision 2626.

More work towards deprecating Wumpus.Basic.Geometry - now none of the shapes depend on it.

I've found another bug in the intersection code. This time it is with straight line / path intersection, which I thought was working (yesterdays problem was with Beziers which I was already dubious about). Both problems are still unresolved.

wumpus-drawing

Copperbox revision 2625.

More work deprecating Wumpus.Basic.Geometry from the Shapes.

Unfortunately I've found another bug in the Path intersection code, specifically in the intersection of a ray and and a Bezier curve. I'll have to resolve this tomorrow.

wumpus-drawing

Copperbox revision 2624.

I've added a module to illustrate AbsPaths so that the Bezier control points can be printed, for instance.

At the moment it is very primitive with just one illustration function.

wumpus

Copperbox revision 2623.

I've properly implemented ellipse trails - as cw or ccw semi-ellipse trails in Wumpus-Basic and then as incline and shape trails in Wumpus-Drawing.

wumpus-drawing

Copperbox revision 2622.

I've implemented a preliminary version of an ellipse trail. To follow other trails it will have to be spilt so it can produce CW and CCW semi-ellipse trails... but this will have to wait until tomorrow.

wumpus-drawing

Copperbox revision 2621.

More work removing uses of Basic.Geometry.

I've fixed the bug noted yesterday, but I still think the Paths.Intersection module needs re-working (certainly better naming would be good).

wumpus-drawing

Copperbox revision 2620.

Work on Shapes - changed Triangle and Diamond to use new intersection code for radial anchors.

The new intersection code has another bug (it had one yesterday that caused the same error in drawing). I think I'll need to rewrite it - it isn't nice code and clearly it doesn't work well, though this may have to wait until the weekend.

wumpus-drawing

Copperbox revision 2619.

I've re-worked the Rectangle shape so it no longer depends on Basic.Geometry.

In some ways this is not a improvement - I expect the new code is a wee bit slower and radial anchors are now found by a sweep which can fail (failure is made total by substituting the center as a fall back anchor); but, the old quadrant code is just too esoteric and needs replacing.

wumpus

Copperbox revision 2618.

More work towards deprecating Basic.Geometry.

I've started a new module ShapeTrails with trail building functions for each shape (only circles and rectangles so far). Shapes will be able to turn these trails into paths then use the new Path.Intersection code to find border anchors.

wumpus-drawing

Copperbox revision 2617.

I've added a module for finding the intersection of an infinite line with a Path. This is a preliminary for removing the Geometry modules from Wumpus-Basic which only serve to find intersections but add a lot of size to the API in doing so.

wumpus-drawing

Copperbox revision 2616.

Following yesterday's comment, I've implemented an adaptor function so BoxConnectors can use InclineTrails and changed the existing box connectors to use it.

wumpus-drawing

Copperbox revision 2615.

I've changed the BoxConnector API so it follows the same instantiation pattern as path connectors (the instantiation is modelled after Parsec's Token module though it is a bit different).

Doing this, I realized box connectors cannot reuse the library of "box" incline trails as the incline trails don't account for spacing (rightfully so). I'll have to write an adaptor function for box connectors to overcome this.

wumpus-drawing

Copperbox revision 2614.

I've reformulated above and below connectors.

Whereas CatTrails have to heed clock direction (as a CatTrail can be continued), I think connectors are free to maintain natural notions of above and below. The code isn't well tested at the moment so this is only a supposition...

wumpus-drawing

Copperbox revision 2613.

I've wrapped Connector paths in a newtype - ConnectorPathSpec. This means they can be uniformly seeded with a single ConnectorProps record - previously they could be seeded with properties for the rendering and the building.

wumpus-drawing

Copperbox revision 2612.

I've added orthonormal horizontal and vertical bar connectors - there absence had been the cause of a long standing bug in one of the examples.

The ConnectorPaths module will need its naming scheme improving; the names are now getting rather silly e.g. connaorthohbar.

wumpus

Copperbox revision 2611.

I've finally sorted out connectors so they draw properly with respect to arms and initial spacers.

wumpus

Copperbox revision 2610.

I've tidied up the API of the Trail module in Wumpus-Basic so how it handles clock directions is now more uniform.

wumpus-drawing

Copperbox revision 2609.

I've gone back to the simpler ConnectorPath representation of revisions 2606 and 2607. I think I can represent ConnectorPaths quite a bit simpler than yesterday's work if I account for spacing and arm length in the path building function rather than tie in the SpacingProjection functions.

Note - all the connectors in the ConnectorPath module will need re-implementing to match this intuition.

wumpus-drawing

Copperbox revision 2608.

More work on connector spacing.

Some connectors are now drawn correctly (for the first time) regarding source and destination spacing. Some connectors are still drawn incorrectly. The new code is rather complicated... so I think all this code needs a rethink.

wumpus-drawing

Copperbox revision 2607.

I've fixed the bug mention yesterday with path end-points. Actually the problem was with shortening the path from the right, after this the wrong end-point was cached so querying the end point would always produce a bad result.

There are still some design issues with the new connector code - I haven't decided if "spacing" should eat into the arm length of jointed connectors; or whether arms should be measured after the spacing has been accounted for.

wumpus-drawing

Copperbox revision 2606.

Work simplifying connector paths and drawing them with arrowheads.

Currently there is a bug with finding the end point of an AbsPath, I'll have to track this down tomorrow.

wumpus

Copperbox revision 2605.

I've added new enumerated types for horizontal and vertical directions. Previously code was using the Quadrant enumeration which meant cases in pattern match were being repeated if I just wanted UPWARDS or RIGHTWARDS.

wumpus

Copperbox revision 2604.

I've reworked Drawing.Extras.Loop so it generates a Trail rather than a Point list.

This has uncovered a bug where path labels are not drawn properly - in the Automata example they seem to get drawn at the start. Any fix for this ought to address the fact that the labelling API isn't very good for starters...

wumpus

Copperbox revision 2603.

Work deprecating Basic.Geometry and cleaning up Drawing.Basis.DrawingPrimitives.

Basic.Geometry doesn't merit its place in Basic as it is only adding code which is used by Shapes in Drawing. As Shapes are quite difficult to implement, Basic.Geometry will probably stick around for a while but at least I'll know not to use it...

Drawing.Basis.DrawingPrimitives is adding quite a few drawing functions that aren't really merited - minor short-hands for functions that exist elsewhere. They are likely to be better off in a more expansive short-hand module that can also provide short-hands for the shapes (for example) and so won't be particularly primitive.

wumpus

Copperbox revision 2602.

I've reworked arrowheads so they use the primitive trails from InclineTrails rather than define their own drawing operations.

wumpus

Copperbox revision 2601.

Work on renovating arrowheads. I haven't made any big changes yet to tip drawing (though this needs to be done), but I've improved the look of the tips with respect to corner mitring / bevelling.

Also I've stopped retract distance being dependent on line width - while it is true that retract distance is dependent on line width it can also be dependent on bevelling, mitring etc. It seems better to handle the nuances within the drawing function for each tip.

wumpus-drawing

Copperbox revision 2600.

I've added a few more incline trails - diamond, chamfered rectangle, tube.

wumpus-drawing

Copperbox revision 2599.

Initial work on Incline Trails - trails formed from a base vector representing west-to-east but at some angle of incline.

Hopefully arrowheads, some box connectors and path vamps should be derivable from incline trails, so they can all share a library of common primitives.

wumpus

Copperbox revision 2598.

I've renamed PlacedTrail to AnaTrail - ana indicating anacrusis / prefix. I didn't like the adjectival prefix Placed and AnaTrail matches better with CatTrail.

wumpus

Copperbox revision 2597.

First round of work updating arrowheads in Wumpus-Drawing to use trails, rather than point-list generators.

wumpus

Copperbox revision 2596.

I've sorted out clock direction for rounding corners, previously it was hacked expecting shapes would be drawn counter-clockwise. Also I've improved the API of the curve trails so they are respective of clock direction, the waveform trails need a similar improvement...

new releases - wumpus

Copperbox revision 2595.

New releases:

wumpus-core-0.52.0
wumpus-basic-0.22.0
wumpus-drawing-0.7.0
wumpus-tree-0.18.0

The changes to Wumpus-Core are cosmetic but important to the higher level layers - renaming clip to clipPrim and changing the types of d2r and r2d. As Wumpus-Core is such a large archive, I've added support for annotating with SVG id attributes to make it a worthwhile Hackage update.

wumpus-drawing

Copperbox revision 2594.

I've updated the demos in Wumpus-Drawing as I intend to make a new set of releases.

wumpus

Copperbox revision 2593.

I've updated Basic adding methods to the Decorate class that implement SVG annotation.

Rounding corners for Paths has been re-implemented in Drawing.

wumpus-core

Copperbox revision 2592.

I've added explicit support for SVG id attributes. Text labels support id directly, other elements have only limited support cascading downwards from a SVG group element.

The rationale for this is to support changing text dynamically via DOM scripting, Wumpus is too static to readily support scripting anything else.

wumpus

Copperbox revision 2590.

I've changed the d2r and r2d functions in Wumpus-Core so that degree is typed to Double rather than a polymorphic a. This means user code can avoid type annotations for the common case where degrees are represented by Doubles.

Copperbox revision 2591.

Updates to Wumpus-Basic and Wumpus-Drawing to work with the Core changes. Also I've stopped exposing jointedAppend from the Path.Base API.

wumpus

Copperbox revision 2589.

First work towards removing jointedAppend from Paths. I've reworked curved arrowheads to use trails rather than AbsPaths (and jointedAppend).

Also I noticed that the curve CatTrail constructors should account for clockwise and counter-clockwise directions...

wumpus-basic

Copperbox revision 2588.

I've optimized trail drawing so that contiguous straight lines in the same direction are coalesced. This is potentially useful for drawing Djembe beam groups in Wumpus-Rhythm.

At the weekend, when I've more time to concentrate, I'll look at removing jointedAppend from Paths in Wumpus-Drawing as AbsPaths aren't really monoidal. Also I suspect there are modules in Wumpus-Drawing that use AbsPath when a trail would be better - Arrowheads is one...

wumpus

Copperbox revision 2587.

I've updated Wumpus-Tree and Wumpus-Rhythm to work with the latest revisions of Basic and Drawing.

wumpus-drawing

Copperbox revision 2586.

I've added a few more Doc symbols - left and right slices and a box.

wumpus-drawing

Copperbox revision 2585.

Preliminary work basing Dots on Symbols - SimpleDots are expected to be fixed sized symbols. Also work on re-defining Symbols as Doc objects so they can be used inside text where otherwise using the Symbol font is controversial for SVG.

wumpus

Copperbox revision 2584.

I've added a module for drawing symbols to Wumpus-Drawing. Dots and potentially DocText should be able to to elaborate these primitive symbols to make their respective objects rather than define their own analogues.

wumpus-basic

Copperbox revision 2583.

I've finally implemented the wedge graphic using trial arcs. 

wumpus-basic

Copperbox revision 2583.

I've renamed yesterday's code as the functions were more correctly circle sweeps rather than arcs. The distinction is how they "join" an existing trail - circle sweeps continue round a guiding circle; an arc would be drawn along a possibly tangential vector.

Tomorrow I'll re-implement arcs as they are needed for Wumpus-Drawing.

wumpus-basic

Copperbox revision 2581.

I've reworked the arc trails to be better cognisant of whether they are drawn in a clockwise or counter-clockwise direction.

wumpus-basic

Copperbox revision 2580.

I've added a trail for circular arcs. Hopefully this will be useful for rounded corners, which unfortunately have never been implemented satisfactorily in Wumpus.

wumpus

Copperbox revision 2579.

I've finally implemented a tube connector - i.e. a box connector with round ends. This has been on my TODO list for as long as there has been the BoxConnectors module in Wumpus-Drawing.

wumpus-basic

Copperbox revision 2578.

I've added some trails for single Bezier curves.

wumpus-basic

Copperbox revision 2577.

More work on waveform trails. I've added sine wave and squiggle wave (semicircles) and improved the API so waveforms are drawn according to the number of repetitions - this produces better paths for waves like square or sawtooth that have lines that are otherwise "split" at the end of a phase.

wumpus-basic

Copperbox revision 2576.

Work on waveform trails - sawtooth and square wave. Eventually these should be useful for decorating connector paths.

wumpus

Copperbox revision 2575.

More work on trails in Wumpus-Basic, I've now added a squiggle trail. Wumpus-Drawing has been updated removing HPath and using CatTrail instead.

wumpus-basic

Copperbox revision 2574.

I've changed GoingTrail to CatTrail and changed the representation to a Hughes list so it supports efficient append. This is so it can replace HPath in Wumpus-Drawing.

wumpus-basic

Copperbox revision 2573.

More work on Trail.

Off-topic, Wumpus's development has slowed down as I'm contracting and have a lot less "free" time. I generally try to do a commit a day, but on days like today the commit can be fairly insubstantial.

wumpus-basic

Copperbox revision 2572.

I've added a new module Trail for what were previously path schemes or point schemes.

I thought of the name Trail this morning on the lines of breadcrumb trails and the Slint song and it seemed to fit better than path scheme (or PrePath, PathPlan...). Coincidentally, I discovered later that Diagrams has a module Trail for Path like functionality - I follow the Diagrams mailing list, but don't know the library well as I haven't been able to build it on Windows.

wumpus

Copperbox revision 2571.

I've changed the argument order of the connect function in Wumpus-Basic. The new order should be better for partial application.

wumpus

Copperbox revision 2570.

Work on Chains and DocText.

Some of the chains are common enough to merit their own run functions - this is a pattern other Wumpus objects should follow.

User state added to DocText.

wumpus-basic

Copperbox revision 2568 and 2569.

I've added user state to PosObject and moved it into Kernel.Drawing so it is with the other obviously monadic objects. Without user state in PosObject, it would be impractical to add user state to the Doc object in Wumpus-Drawing.

wumpus

Copperbox revision 2567.

I've updated the demos in Basic and Drawing so they work with the new changes to the argument order of the monadic run functions.

wumpus-basic

Copperbox revision 2566.

I've changed the arg order of the monadic run functions to follow the monadLib style (args then monadic operation) rather than the MTL style (monadic operation then args).

Using the MTL style was as good as forcing code to use where clauses for the monadic operation if they wanted to be typographically neat, whereas the monadLib style can be linear by using ($).

Wumpus-Drawing needs updating to follow this convention.

wumpus-drawing

Copperbox revision 2565.

I've updated the demos so they compile again.

At some point I should re-work them so they are more exemplary - currently they are really just test cases.

wumpus-drawing

Copperbox revision 2564.

I've changed the behaviour of pen updating in PathBuilder so it now does what I expect. This has changed the interface so it is a state update rather than a localize (cf. the Writer monad).

Off topic - Happy Birthday J.W.

wumpus-drawing

Copperbox revision 2563.

I've updated all the library code to work with the Path changes in Wumpus-Basic - removal of PathAlgs and replacing the DrawStyle enum type by two enums DrawMode and PathMode.

The demos will need updating.

wumpus

Copperbox revision 2562.

I've removed the PathAlgs code from Wumpus.Basic.Geometry. Having another Path type here was not really merited as it proliferated the number of Path-like objects. I've updated some of Wumpus-Drawing to accommodate this, but at least the shapes are currently broken. Also I've discovered a bug with localPen in the PathBuilder module that's been around a while.

wumpus-basic

Copperbox revision 2561.

I've added more vector constructors to Displacement, there is now a good set of angular vector builders. Also I've changed the DrawStyle enum and added a similar enum for open and closed paths. This should help reduce the proliferation of path drawing functions in Wumpus-Drawing.

wumpus-drawing

Copperbox revision 2560.

I've added a new module Paths.HPath for lightweight modular Path building. Paths.Base is not modular as it works directly with absolute paths which don't readily concatenate,  Paths.PathBuilder is modular, but heavyweight as it supports arbitrary decoration during path building.

wumpus-drawing

Copperbox revision 2559.

I've updated the demos to work with the connector changes. As connector props are no longer in the Drawing Context, connectors should now be instantiated with a properties record. This is as per the Token module in Parsec.

wumpus-drawing

Copperbox revision 2558.

I've added path division which is a preliminary step towards decorating paths. Because path shortening and tip point and direction queries were already in place, the code was pleasingly simple - it took me more time to realize I already had the pieces in place than it did to code the final algorithm.

wumpus-drawing

Copperbox revision 2557.

I've fixed the bug with connector spacing / direction that crept in with the last commit. Connectors with spacing now draw correctly for all the connectors except the Bezier curves.

wumpus

Copperbox revision 2556.

I've changed connectors so the connector props are no longer in the DrawingContext and the new implementation should always respect the source and destination separators (they were largely ignored before).

Currently the implementation is a bit buggy...

wumpus

Copperbox revision 2555.

Fixed a bug in chains where tables counted the row/column iterations incorrectly (Wumpus-Basic).

Finally implemented the squareWE path vamp (Wumpus-Drawing).

wumpus

Copperbox revision 2554.

Preliminary work drawing labelled axes for grids. This highlighted a bug in chains where the start point was iterated with the next-state function before anything had been drawn. The result being that chains never started at the start point.

wumpus

Copperbox revision 2553.

Updates to the demos in Wumpus-Drawing, plus Tree and Rhythm to work with the Path module name changes.

wumpus-drawing

Copperbox revisions 2551 and 2552.

I've updated the directory hierarchy for Paths now that only AbsPaths are supported. Revision 2551 is the code changes, revision 2552 deletes the old Wumpus.Drawing.Paths.Base directory.

wumpus-drawing

Copperbox revision 2550.

I've changed PathBuilder to build AbsPaths rather than RelPaths. Also I've simplified the API of AbsPath to promote the idea of extension rather than concatenation.

wumpus

Copperbox revision 2549.

I've bumped version numbers in the cabal files in Wumpus-Basic and Wumpus-Drawing, and I've changed the representation of AbsPath in Drawing. I think Wumpus-Drawing should be able to manage with one path type, rather than need both absolute paths and relative paths. The first step towards this is changing AbsPath so it supports cheap movement, with cheap movement it should be able to cover the use-cases that RelPath previously handled.

new releases - wumpus-basic-0.21.0, wumpus-drawing-0.6.0 and wumpus-tree-0.17.0

Copperbox revision 2547.

Updates to demos and cabal files prior to new releases for Hackage.


Copperbox revision 2548.

New release archives including Wumpus-Tree this time.

wumpus-basic-0.21.0
wumpus-drawing-0.6.0
wumpus-tree-0.17.0

The most notable change is the new distinction in Wumpus-Basic between "drawings" (collective) and graphic "objects" (elementary - possibly grouped). The includes the new LocDrawing module.

wumpus-tree

Copperbox revision 2546.

I've simplified the one-to-many connector type back to almost its old definition, and uncommented the drawing functions for the other connector styles. All the example trees in Demo01 draw correctly again.

wumpus

Copperbox revision 2545.

I've changed the implementation of LocDrawing so that the run function uses translation, rather than monadically thread an immutable start point (Reader). Trying to thread a start point was tying me up in semantic knots - a rethink was necessary.

This has got simple radial connector tree drawing working again (last commit it compiled but ran with a bug). The other connectors need re-implementing.

wumpus-tree

Copperbox revision 2544.

Initial work getting Wumpus-Tree to compile again.

The simplest example compiles again, but a lot of code is out of spec (Wumpus-Tree was actually somewhat broken when I diverted my attention to ZSnd / Majalan), so it looks like it needs a substantial re-design.

wumpus-basic

Copperbox revision 2543.

I've added a new drawing LocDrawing that effectively supports a local coordinate system. It works like TraceDrawing, but the result is a LocImage not a picture, so the drawing can be moved, redrawn etc. within a single affine frame.

wumpus

Copperbox revision 2542.

Updates to get Wumpus-Rhythm back working - bug fix to PosObject in Wumpus-Basic re-enabled pivot path drawing in Wumpus-Drawing.

wumpus-basic

Copperbox revision 2541.

I've moved LocTrace into Wumpus-Basic from Wumpus-Drawing and improved the code so it follows the pattern of the Chain module. The two modules are almost the same, but Chain consumes next moves from a supply of points, whereas LocTrace controls where to go next with turtle like movement.

wumpus-drawing

Copperbox revision 2540.

I've updated Wumpus-Drawing to work with the combinator changes in Wumpus-Basic.

Unfortunately the code seems to be one function call longer in many places, but at least it is uniform.

wumpus-basic

Copperbox revision 2539.

I've rationalized the set of combinators exported by the Image, LocImage, LocThetaImage and Connector types. They not have combinators to promote to the object or query; combinators to apply the object or query; and combinators to change between object and query.

wumpus-basic

Copperbox revision 2538.

More restructuring - I've made a separate directory for the collective drawing modules Chain, CtxPicture and TraceGraphic. Elementary drawing objects remain in Kernel.Objects.

wumpus-basic

Copperbox revision 2537.

I've moved the Image and Query types from the Objects.Basis module into their own module Objects.Image.

new releases - wumpus-basic-0.20.0 & wumpus-drawing-0.5.0

Copperbox revision 2536.

New releases for Wumpus-Drawing and Wumpus-Basic.

I won't be making a version of Wumpus-Tree to match these releases as I consider them somewhat interim releases. There are a lot of changes in Wumpus-Basic, which is why I want to put out a new release; but the changes haven't really been consolidated in Wumpus-Drawing. If I waited until I had a consolidated release of Wumpus-Drawing, the change delta may be huge, so putting out the current interim seems preferable.

Wumpus-Basic-0.20.0
Wumpus-Drawing-0.5.0

wumpus-drawing

Copperbox revision 2535.

I've updated most of the examples to run again. A couple are now out-of-spec with Wumpus-Drawing's capabilities, so I've left them as is. I think all the distributed examples compile.

wumpus-drawing

Copperbox revision 2534.

I've removed the out-of-date text modules and updated the Multi-line example.

wumpus

Copperbox revision 2533.

I've re-implemented DocText to use PosObject directly, previously the implementation interpreted a syntax tree. The new version is much clearer.

Note - the Text modules in Drawing will need a re-organization as some have been superseded by new code in Wumpus-Basic.

wumpus-basic

Copperbox revision 2532.

I've added rotate text drawing to PosObject.

This is only applicable to single-line text - multi-line text would need a new set of concatenation operations to account for incline.

wumpus-basic

Copperbox revision 2531.

I've moved and re-implemented the simple text functions (PosChar, single and multi-line text) from Wumpus-Drawing to Wumpus-Basic. The PosObject module seems a better home for them.

wumpus-basic

Copperbox revision 2530.

Initial work moving the simple text elements, the ones that just rely on PosObject, from Wumpus-Drawing to Wumpus-Basic. The single character and single line objects don't really merit their own modules - so I'm moving them into the PosObject module.

wumpus-basic

Copperbox revision 2529.

I've changed the obliterate method of the Decorate class. Implementations are now expect to simply swap and accumulated CatPrim for mempty.

wumpus-drawing

Copperbox revision 2528.

I've re-implemented monadic path building. The new version follows the recent improvements to monadic builders like Chain where the run function produces a LocImage and so the monad can support the general drawing classes like DrawingCtxM.

wumpus

Copperbox revision 2527.

The demos are working again in Basic and Drawing. Pleasingly, the demos that use chains didn't need much to update them. The new chain representation seems like a good improvement, but its handy that the API is almost the same.

wumpus-basic

Copperbox revision 2526.

I've changed the argument order of the run functions to be more conventional (monadic expression first, parameters following). I actually prefer the other way round, but with reflection, being conventional seems better.

wumpus-basic

Copperbox revision 2525.

I've added user state to the Chain monad.

wumpus-basic

Copperbox revision 2524.

I've added Parsec-like user state to the TraceDrawing monad. This should compensate for the loss of expressiveness due to removing the transformer version.

User state is a generic class - adding it to at least Chain is pending...

wumpus-basic

Copperbox revision 2523.

I've updated the demos so they run again and fixed a bug in rendering PosObjects with bounding boxes.

wumpus-basic

Copperbox revision 2522.

I've re-implemented Chains as a monadic type with an explicit next operation to draw a node and advance the chain.

This is a refinement of the work from Majalan.

wumpus-drawing

Copperbox revision 2521.

I've updated the library code so that Wumpus-Drawing works with the changes to Wumpus-Basic. It is likely some of the examples will need updating.

wumpus-basic

Copperbox revision 2520.

As per the previous post, I've simplified the PosObject type to a reader-writer monad.

wumpus-basic

Copperbox revision 2519.

I've simplified the implementation of AdvObject so it is a fairly idiomatic reader-writer monad, previously it was a rather esoteric "split" object.

Again, this is another simplification due to Majalan.

wumpus-basic

Copperbox revision 2518.

I've removed the transformer version of TraceDrawing. Again, this follows the Majalan experience where it was not possible to implement run functions for transformer versions of many drawing objects. It is actually possible to write a run function for TraceDrawingT but favouring uniformity suggests it is not a compelling exception.

wumpus-basic

Copperbox revision 2517.

I've removed the PrimW type and made the code that previously used it follow the more idiomatic Reader monad style.

This is the first of the code improvements due to Majalan.

majalan-basic

Copperbox revision 2516.

I've remade the PosEvent type. Previously it had a rather exotic implementation because concatenating two PosEvents needed the orientation of the second before it could be computed (!). To avoid this I've added cheap displacement to the event answer type CatPrim. This means CatPrims can be moved after they have been computed, so PosEvent can directly support arrangements such as overlay or side-to-side.

Again, this is another improvement that would be good to back port to Wumpus.

majalan-basic

Copperbox revision 2515.

I've removed the PrimW type so code that collects CatPrims is more like regular Writer monad code. Again, this another simplification that should transfer to Wumpus.

majalan-basic

Copperbox revision 2514.

I've re-implemented AdvEvent as a monad. It actually took quite a bit of debugging so I'd hasten to call the code a definitive improvement on the old version, but it does use prosaic technology (State + Reader) unlike its predecessor. So, it's probably a win on points and a candidate for porting back to Wumpus .

majalan-basic

Copperbox revision 2513.

I've improved the Chain type so the state is hidden by an existential. This should allow changing chain scheme mid chain as per TikZ. Also, I've added two sample chain schemes.

majalan-basic

Copperbox revision 2512.

I've changed the "next step" code for chains. With the previous formulation I couldn't work out how to write any interesting iterators, with the new one anything that can be written as a unfold should be implementable.

majalan-basic

Copperbox revision 2511.

I've removed the transformer versions of the Chain and Turtle monads. The type changes to the non-transformer monads to allow them to use localize on the context invalidated the run functions of the transformers. As I think the new types are the right way to go, I've removed the transformers.

majalan-basic

Copperbox revision 2510.

Work on score representations - primarily the Turtle score object (and design variation CtxTurtle). This has an unfortunate name, but essentially it models turtle drawing as sometimes used in Wumpus.

The work so far has unearthed some problematic design ideas with Wumpus, particularly in relation to context handling - CtxTurtle in Majalan can support the local operation of a reader monad whereas the counterparts in Wumpus cannot.

majalan-basic

Copperbox revision 2509.

I've updated Majalan-Basic to match the changes to instrument number resolution in Majalan-Core.

majalan-core

Copperbox revision 2508.

I've changed the instrument number resolution to use a dictionary of (byte) string keys. Whilst this potentially allows conflicts that the previous version avoided it is substantially simpler, so the trade off is acceptable.

fmss

Copperbox revision 2507.

I've updated the FM bell example so it works again. The output now seems to be correct: no syntax errors and "fully featured", i.e. no tricky bits left unimplemented.

fmss

Copperbox revision 2506.

Major simplification / re-working of FMSS.

I've removed the translation phase and changed the ConfigMonad so that FMSS now works essentially as a macro-expander. The ConfigMonad no longer produces a set of datatypes that are translated into Csound code, instead it emits Csound statements "directly". Some ConfigMonad operations actually produce 2 or 3 lines of Csound code, but otherwise there is no translation hence it works like a macro-expander.

I actually spent all of Saturday and Sunday making FMSS much bigger and more complicated (none of the immediate results were worth committing to Copperbox). It had got so complicated by Sunday evening, that I decided all the new code was invalid and a simplification was desperately needed.

fmss

Copperbox revision 2505.

I've added error handling to the Spec monad so it detects if variable names are used twice (Csound has no shadowing). Also I've added a more sophisticated example - FM bell, though it is not yet complete.

majalan-core

Copperbox revision 2504.

Some tidying up of the Score datatypes.

majalan-symbolic

Copperbox revision 2503.

Adding "symbolic" modules for scale representation. Hopefully there are other useful symbolic objects as well as scales / pitches...

majalan-basic

Copperbox revision 2501.

Updated to match the changes to Timespan in Majalan-Core.

majalan-core

Copperbox revision 2501.

I've made Timespan a separate module, and added more operations that work on Timespans.

majalan-basic

Copperbox revision 2500.

I've separated the instrument number table from the context in the event types. This has made the types more complicated, but it does seem the right thing to do.

majalan

Copperbox revision 2499.

I've added a port of ZSnd-Basic - now majalan-basic. 

The example works, but the code is currently problematic. One of Majalan-Core's design principles is that instrument numbers should be resolved at "link time". This is to increase the modularity of scores, it should be possible to code an instrument's performance with out hard coding the instrument number. For example I might want to code a drum part without knowing that a snare drum will always be instrument 7 in the orchestra.

In Majalan-Core, I specify instrument numbers only when I link together all the parts of a score. Majalan-Basic roughly supports this but it is mixed up with the Context code and it is messy.

majalan

Copperbox revision 2498.

I've started a new project Majalan - this is a replacement for ZSnd that will only generate Csound scores. Instrument definitions will either be hand coded or generated by FMSS. 

fmss

Copperbox revision 2497.

I've added the capability for cycles to the oscillator configuration.

A downside - the translation code is becoming very clunky, at some point I'll probably redo it entirely.

fmss

Copperbox revision 2496.

I've added a second monad which supports variable binding - this is so a single envelope declaration can be shared by multiple oscillators.

I've called the new monad Spec which was the name I used yesterday for the other monad. Yesterday's monad is now called Config. Config is the patching of oscillators cf. an algorithm in DX7 terminology. Spec is an FM instrument that instantiates a Config with particular oscillators.

fmss

Copperbox revision 2495.

I've added a monad for specifying modulator-carrier connection patterns. A DX7 style algorithm will look something like this (cycles not yet implemented):


algo28 :: Config6 -> Spec ()
algo28 (Config6 o1 o2 o3 o4 o5 o6) = do
    m2 <- modulator o2
    m5 <- modulator o5
    m4 <- modulator o4
    c1 <- carrier   o1
    c3 <- carrier   o3
    c6 <- carrier   o6
    m2 =>- c1
    m5 =>= m4
    m4 =>- c3
    -- m5 should be cycled
    return ()

fmss

Copperbox revision 2494.

I've put the translation code in a monad so I can handle failure properly.

fmss

Copperbox revision 2493.

New project fmss - fm synthesizer synthesizer.

fmss aims to generate only FM synthesizers in Csound, rather than be a general DSL for Csound instruments. FM instruments in Csound can be implemented fairly uniformly which indicates a generator might be promising. Particularly, the input descriptions should be more succinct than the Csound they generate. My previous attempts with Zsnd had the problem that the instrument definitions were always much bigger than the equivalent Csound instruments. The sole benefit (not always realized) was that ZSnd instruments could be a bit more modular.

fm-bell

Orch:

sr = 44100
kr = 4410
ksmps = 10
nchnls = 1

;
; This is fm-bell written by Michael McNabb and distributed with 
; CLM (Common Lisp Music). The CLM original is in the file 
; fmex.ins. 
;

; TODO - the envelopes are parametric in CLM. 
; Potentially they should be put in a table in the score. 

instr 1
  isinetbl      = 1
  idur          = p3
  iamp          = p4
  ifreq         = p5
  indx          = p6
  ifm1index     = 32.0 * ifreq
  ifm2index     = 4.0 * (8.0 - ifreq / 50.0)
  ifm3index     = ifm2index * 0.705 * (1.4 - ifreq / 250.0)
  ifm4index     = 32.0 * (20.0 - ifreq / 20.0)
  imod1freq     = ifreq * 2.0
  imod2freq     = ifreq * 1.41
  imod3freq     = ifreq * 2.82
  imod4freq     = ifreq * 2.4
  icar1freq     = ifreq
  icar2freq     = ifreq
  icar3freq     = ifreq * 2.4

  ; index envelope
  kindxenv  expseg 1.0, idur, .01


  ; amp envelope
  kampenv   expseg .01, .002, 1, idur-.002, .01


  ; modulator 1
  amod1phs  phasor  imod1freq
  amod1sig  tablei  amod1phs, isinetbl, 1, 0, 1

  amod1sig  = (ifm1index * indx * kindxenv) * amod1sig

  ; carrier 1
  acar1phs  phasor icar1freq + amod1sig
  acar1sig  tablei acar1phs, isinetbl, 1, 0, 1


  ; modulator 2
  amod2phs  phasor  imod2freq
  amod2sig  tablei  amod2phs, isinetbl, 1, 0, 1

  ; modulator 3
  amod3phs  phasor  imod3freq
  amod3sig  tablei  amod3phs, isinetbl, 1, 0, 1

  ; amod2sig now sums amod2sig and amod3sig
  amod2sig  = kindxenv * ((ifm2index * amod2sig) + (ifm3index * amod3sig))

  ; carrier 2
  acar2phs  phasor icar2freq + amod2sig
  acar2sig  tablei acar2phs, isinetbl, 1, 0, 1


  ; modulator 4
  amod4phs  phasor  imod4freq
  amod4sig  tablei  amod4phs, isinetbl, 1, 0, 1

  amod4sig  = (ifm4index * indx * kindxenv) * amod4sig


  ; carrier 3
  acar3phs  phasor  icar3freq + amod4sig
  acar3sig  tablei  acar3phs, isinetbl, 1, 0, 1

            out iamp * kampenv * (acar1sig + (0.15 * acar2sig) + (0.15 * acar3sig))

endin

Score:

; Table #1: sinewave
f 1 0 1024 10 1

; 1   2    3    4      5       6    
; #   st   drn  amp    freq    index
i 1   0    5.0  20000  233.046 0.750

e

fm-tubular-bell

Orch:

Note I haven't given much attention to the envelopes.

sr = 44100
kr = 4410
ksmps = 10
nchnls = 1

;
; This is fm-tubular-bell from Nicky Hind\'s CLM tutorials:
; https://ccrma.stanford.edu/software/clm/compmus/clm-tutorials/fm2.html
; 
; Note - amplitude in CLM is 0..1 in Csound it is 0..2^15 (I think...)

instr 1
  isinetbl      = 1
  idur          = p3
  iamp          = p4
  ifreq         = p5
  iampfrac      = iamp / 32768
  iamp1         = p6                    ; default 0.5
  iamp2         = p7                    ; default 0.25
  iamp3         = p8                    ; default 0.25
  iamp1level    = iamp * iamp1
  iamp2level    = iamp * iamp2
  iamp3level    = iamp * iamp3
  ic1rat        = p9                    ; default 2.0
  im1rat        = p10                   ; default 5.0
  ic2rat        = p11                   ; default 0.6
  im2rat        = p12                   ; default 4.8
  ic3rat        = p13                   ; default 0.22
  im3rat        = p14                   ; default 0.83
  indxmin       = p15                   ; default 0.15
  indx1scl      = p16                   ; default 3.0
  indx2scl      = p17                   ; default 2.0
  indx3scl      = p18                   ; default 1.0
  indx1max      = iampfrac * indx1scl * ((261.5 / ifreq) ^ 3) 
  indx2max      = iampfrac * indx2scl * ((261.5 / ifreq) ^ 3) 
  indx3max      = iampfrac * indx3scl * ((261.5 / ifreq) ^ 3) 
  imod1scaler   = (indx1max - indxmin) * im1rat * ifreq
  imod2scaler   = (indx2max - indxmin) * im2rat * ifreq
  imod3scaler   = (indx3max - indxmin) * im3rat * ifreq
  imod1offset   = indxmin * im1rat * ifreq
  imod2offset   = indxmin * im2rat * ifreq
  imod3offset   = indxmin * im3rat * ifreq


  ; index envelope
  kindxenv  expseg 1.0, idur, .01


  ; amp envelope
  kampenv   expseg .01, .002, 1, idur-.002, .01

  ; modulator 1
  amod1phs  phasor  ifreq * im1rat
  amod1sig  tablei  amod1phs, isinetbl, 1, 0, 1

  amod1sig  = (imod1offset + imod1scaler * kindxenv) * amod1sig

  ; carrier 1
  acar1phs  phasor (ifreq * ic1rat) + amod1sig
  acar1sig  tablei acar1phs, isinetbl, 1, 0, 1

  acar1sig  = iamp1level * kampenv * acar1sig

  ; modulator 2
  amod2phs  phasor  ifreq * im2rat
  amod2sig  tablei  amod2phs, isinetbl, 1, 0, 1

  amod2sig  = (imod2offset + imod2scaler * kindxenv) * amod2sig

  ; carrier 1
  acar2phs  phasor (ifreq * ic2rat) + amod2sig
  acar2sig  tablei acar2phs, isinetbl, 1, 0, 1

  acar2sig  = iamp2level * kampenv * acar2sig


  ; modulator 3
  amod3phs  phasor  ifreq * im1rat
  amod3sig  tablei  amod3phs, isinetbl, 1, 0, 1

  amod3sig  = (imod3offset + imod3scaler * kindxenv) * amod3sig


  ; carrier 3
  acar3phs  phasor  (ifreq * ic2rat) + amod2sig
  acar3sig  tablei  acar3phs, isinetbl, 1, 0, 1

  acar3sig  = iamp3level * kampenv * acar3sig

            out acar1sig + acar2sig + acar3sig

endin

Score:

; Table #1: sinewave
f 1 0 1024 10 1

; 1   2    3    4      5       6     7     8     9      10
; #   st   drn  amp    freq    amp1  amp2  amp3  c1rat  m1rat
i 1   0    3.0  20000  261.61  0.5   0.25  0.25  2.0    5.0
         ; 11     12     13     14     15     16      17      18
         ; c2rat  m2rat  c3rat  m3rat  ixmin  ixscl1  ixscl2  ixscl3 
           0.6    4.8    0.22   0.83   0.15   3.0     2.0     1.0

e

fm-gong

Here's a transliteration of the fm-gong from the CLM distribution:

Orch:

sr = 44100
kr = 4410
ksmps = 10
nchnls = 1

;
; This is fm-gong written by Paul Weineke and distributed with
; CLM (Common Lisp Music). The CLM original is in the file 
; fmex.ins. 
;


instr 1
  isinetbl      = 1
  idur          = p3
  iamp          = p4
  ifreq         = p5
  imod1fq       = ifreq * 1.16
  imod2fq       = ifreq * 3.14
  imod3fq       = ifreq * 1.005 
  indx1a        = .01 * imod1fq
  indx1b        = .30 * imod1fq
  indx1scaler   = indx1b - indx1a
  indx2a        = .01 * imod2fq
  indx2b        = .38 * imod2fq
  indx2scaler   = indx2b - indx2a
  indx3a        = .01 * imod3fq
  indx3b        = .50 * imod3fq
  indx3scaler   = indx3b - indx3a  


  ; mod1 envelope (CLM fmup)
  kmod1env  linseg  0, idur*0.75, 1, idur*.23, 1, idur*.02, 0

  ; mod2 envelope (CLM fmdwn)
  kmod2env  linseg  0, idur*.02, 1, idur*.98, 0

  ; mod3 envelope (CLM rise)
  kmod3env  linseg  0, idur*.15, 0.3, idur*.15, 1, idur*.45, 0.5, idur*.25, 0

  ; amp envelope
  kampenv   expseg .01, .002, 1, idur-.002, .01

  ; modulator1
  amod1phs  phasor  imod1fq
  amod1sig  tablei  amod1phs, isinetbl, 1, 0, 1

  amod1sig  = (indx1a + indx1scaler * kmod1env) * amod1sig

  ; modulator2
  amod2phs  phasor  imod2fq
  amod2sig  tablei  amod2phs, isinetbl, 1, 0, 1

  amod2sig  = (indx2a + indx2scaler * kmod2env) * amod2sig

  ; modulator3
  amod3phs  phasor  imod3fq
  amod3sig  tablei  amod3phs, isinetbl, 1, 0, 1

  amod3sig  = (indx3b + indx3scaler * kmod3env) * amod3sig


  ; carrier
  acarrphs  phasor  ifreq + amod1sig + amod2sig + amod3sig
  acarrsig  tablei  acarrphs, isinetbl, 1, 0, 1


            out iamp * kampenv * acarrsig


endin

Score:

; Table #1: sinewave
f 1 0 1024 10 1

; #   st   drn  amp    freq
i 1   0    3.0  20000  261.61

It was a lot easier to make this one than the fm-drum.

fm-drum

Vis the previous post, the code is a translation to Csound of Jan Mattox's fm drum that is distributed with CLM (Common Lisp Music).

The "low" drum seems sonically pretty close to the original, the "high" drum sounds somewhat different, though I can't work out why.

It turned out to be a lot of effort porting from CLM (which I didn't know at all) to Csound (which I clearly didn't know that well...), hence I haven't updated Copperbox recently. Developing instruments does seem to need a lot of domain knowledge which is perhaps not easy to acquire, certainly if you view instrument building as a "programming" exercise. Maybe it is easier for electronic engineers.

fm-drum

Orch:

sr = 44100
kr = 4410
ksmps = 10
nchnls = 1

;
; This is fm-drum written by Jan Mattox and distributed with
; CLM (Common Lisp Music). The CLM original is in the file 
; fmex.ins. 
;
; Note - the low drum is pretty close to the CLM original, but the 
; high drum is some way off.
;


instr 1
  isinetbl      = 1
  idur          = p3
  iamp          = p4
  ifreq         = p5
  iindx         = p6
  ihigh         = p7
  inoiseamp     = 1000.0
  icasrat       = (ihigh > 0 ? 8.525 : 3.515)
  imodrat       = (ihigh > 0 ? 3.414 : 1.414)
  iamprise      = 0.015
  iamp1decay    = (idur < 0.18 ? 0.5 * idur : 0.18)
  iamp2decay    = idur - (iamprise + iamp1decay)
  icascadehz    = ifreq * icasrat
  imodhz        = ifreq * imodrat
  icarrhz       = ifreq
  idevscaler    = 7000
  icascscaler   = iindx * icascadehz 
  imodscaler    = iindx * imodhz
  iglsscaler    = (ihigh > 0 ? 66.0 : 0.0)

  

  ; modulator indices
  kindxenv    transeg .01, .015, 2,  1, .085, -1, 0.333,  idur-.10, -1, .012

  ; noise envelope does not decay to zero...
  ; In CLM there is a minor difference for high and low but it 
  ; seems to do little in the generated waveform.
  knoiseenv   expseg  .01, .015, 1, .005, 1, .010, .1, .040, .002, idur-.070, 0.01

  ; amplitude envelope...
  kampenv     transeg .01, iamprise, 1, 1.0, iamp1decay, 2, .75, iamp2decay, -8, .001


  ; gls envelope
  kgls        linseg 0, idur*0.25, 0, idur*.5, 1, idur*.25, 1

  ; deviation
  adev1     rand inoiseamp
  adevsig   = idevscaler * knoiseenv * adev1
  adevsig   = (icasrat * iglsscaler * kgls) + adevsig 

  ; cacasade 
  acascphs  phasor  icascadehz + adevsig
  acascsig  tablei  acascphs, isinetbl, 1, 0, 1

  acascsig  = icascscaler * kindxenv * acascsig 
  acascsig  = (imodrat * iglsscaler * kgls) + acascsig

  ; modulator
  amodphs   phasor  imodhz + acascsig
  amodsig   tablei  amodphs, isinetbl, 1, 0, 1

  amodsig   = imodscaler * kindxenv * amodsig
  amodsig   = (iglsscaler * kgls) + amodsig

  ; carrier
  acarrphs  phasor  icarrhz + amodsig
  acarrsig  tablei  acarrphs, isinetbl, 1, 0, 1
  
            out iamp * acarrsig * kampenv

endin

Score:

; Table #1: sinewave
f 1 0 1024 10 1

; #   st   drn  amp    hz  ix   hi
i 1   0    1.5  20000  55  5    0
i 1   2    1.5  20000  66  4    1

zsnd-core

Copperbox revision 2492.

I've added the zak opcodes and fixed a couple of bugs in the score generation code.

zsnd-core

Copperbox revision 2491.

I've changed the Score language so instrument parameters are CsValues - this means they can be Ints or Doubles. It also means they can be Strings, though I don't know that there is a need for this. Maybe I'll have to restrict to just Int - Double at some point.

zsnd

Copperbox revision 2490.

Updates fleshing out the monadic layer of the new Inst language so it can handle the Xanadu instrument. Tidying up some code in ZSnd-Basic.

zsnd-core

Copperbox revision 2488.

I've re-implemented the instrument language, no longer is it based on Click. The new version is significantly lower level, but it can manage control flow via labels and goto - not handling control flow was a significant deficiency of the Click version and the reason for its scrapping.

Quite a few of the details still need to be worked out in the monadic layer, though I've updated all the opcodes which is a significant effort and the simple demo instrument works.


Revision 2489 - deleted old files from the Click version.

zsnd-core

Copperbox revision 2486.

I've added composition operators - scoOver, scoBeside - to combine scores and hopefully debugged the score output code that was stopping them work correctly.

Update - revision 2487.

I've changed the score output so it now works for both overlay and sequential append. I'm not entirely happy with the generated scores as they probably aren't very efficient Csound, but they will do for the time being.

zsnd-basic

Copperbox revision 2485.

I've removed the Onset notelist - it had bad properties that weren't easy to rectify so its removal seems better. It is superseded by TraceLoc, which doesn't suffer from the same problems though it is more limited as a structure.

zsnd-basic

Copperbox revision 2484.

Updates to work  with ZSnd-Core changes.

Note, OnsetNotelist has a bug where the placement of notes is wrong after a tempo change - while I've identified where the bug lies, I'm currently stumped as to how to fix it...

zsnd-core

Copperbox revision 2483.

I've remade the score datatypes so they are closer to the picture datatypes in Wumpus-Core - scores now have a Timespan (analogue to a bounding box) and a frame that abstracts the first event time. This allows scores to be moved cheaply so I can implement "picture language" like operations to combine scores.

zsnd-core

Copperbox revision 2482.

Following up the last commit, I've added table-offset  to the monadic builder so table indexing within an instrument is parametric. Generally numbers will be contiguous within an instrument from some start point.

zsnd-core

Copperbox revision 2481.

I've changed table references (in Csound fields named ifn or similar) so they are distinct from ports in the syntax. This is should improve the modularity of Inst definitions which were otherwise liable to have table number conflicts when multiple instruments were used.

Note, I still have to improve the build monad so it treats table numbers as offsets rather than absolute values.

zsnd-symbolic

Copperbox revision 2480.

Preliminary work on pitch / scale support. I've replaced the PitchClass module with one for 12 tone EqualTemperament and added a module for Kraig Grady's Centaur scale - I want to consider alternative scales from the start rather than shoe horn them in later.

zsnd

Copperbox revision 2479.

I've added some more opcodes to Core - the physical model of vibes and others. This is so I've some default instruments to use for building the higher-level layers.

Also I've added OnsetNotelist to Basic. This is a note list for instruments without dynamic prolongation like vibes, each note has the same duration but the onsets can start with different advances.

zsnd-core

Copperbox revision 2478.

I've changed the IRate phantom unit to IInit as the i-prefix in Csound doesn't actually correspond to a rate (i is initialization time).

Also I've added some more filter opcodes.

zsnd-core

Copperbox revision 2477.

I've added pseudo-opcodes for assignment, these produce assignment statements in the generated Csound code, but are treated exactly like declarations in ZSnd (so the Click language can schedule them when all ports are saturated).

zsnd-core

Copperbox revision 2476.

I've extended the arity of the index functions to go up to 11 -  this should cover all but pathological cases.

zsnd-core

Copperbox revisions 2474 and 2475.

I've changed the Inst directory to CsoundInst so the naming scheme for scores and instruments is more uniform. Also Inst.HighLevel becomes CsoundInst.Typed and Inst.MonadicDefn becomes CsoundInst.Monadic.

zsnd-core

Copperbox revision 2473.

I've updated all the opcodes to work with the new Click representation and reimplemented the monadic layer (so definitions can use the do-notation).

zsnd-core

Copperbox revision 2472.

I've replaced the old implementation of Click with the code from ClickNew and deleted ClickNew. The helpers that were in the working example NewPortSpec have been put into their own modules.

Note - there is still a lot of code to move over to the new Click implementation - the monadic layer which allows Inst definitions to be built with the do-notation and all the opcodes.

zsnd-core

Copperbox revision 2471.

I've sorted out dependency resolution in the new Click implementation, so the example now works properly.

zsnd-core

Copperbox revision 2470.

I've added a new version of Click that builds the result Csound instrument from a dependency graph rather than generating 1-1 a statement for each declaration (regardless of whether the declaration is used).

The new Click code is unfinished - port assignment doesn't work.

zsnd-core

Copperbox revision 2469.

I've added local variable declarations to the Click Inst definitions. I haven't tested them yet to see if the make complex instrument definitions easier. Hopefully global variables should follow the pattern used for local variables when I come to add them.

zsnd-core

Copperbox revision 2468.

Work tidying up the Inst code.

I'm looking towards adding variables into the Inst definition - translating the Xanadu instrument without them was too difficult. But, I'm not sure where variables should fit in the syntax, so I've tidied up the code and removed some out-of-date comments first.

zsnd-core

Copperbox revision 2467.

I've now replaced the old instrument definition with the new Click port style definition. All the opcodes have been updated, which was quite a slog, and ZSnd-Core is functional again (no broken code or examples).

zsnd-core

Copperbox revision 2466.

I've added a typed monadic layer for the Click instrument language, so the Click language is nearly powerful enough to replace the original instrument language.

zsnd-core

Copperbox revision 2465.

I've changed the representation of Click syntax to be a list of statements rather than a nested Let-declaration. This simplifies the current code and should make it easier to add a monadic layer on top for building instruments.

zsnd-core

Copperbox revision 2464.

I've added automatic parens insertion to the expression pretty printer.

zsnd-core

Copperbox revision 2463.

The previous translation from Click to Inst definition had severe problems that I didn't spot whilst coding it. I've replaced it wholesale with a new translation scheme. Note, in the new version there is a bug with embedded ports where the port is within a larger expression that needs to be ironed out.

zsnd-core

Copperbox revision 2462.

Port assignment now works when generating code from the Click style definitions.

Next, I've got to re-implement expression handling and all the named opcodes...

zsnd-core

Copperbox revision 2461.

I've worked up the translation from Click style definitions to Csound instruments so that is accurate - opcode invocations are in the right place and only one is generated.

Ports still need to be handled, so I cannot generate working instrument definitions just yet.

zsnd-core

Copperbox revision 2460.

Initial work on building instruments with syntax patterned after the Click modular router configuration language, rather than using do notation syntax. This might lead to more manageable instrument definitions. 

There is a lot of work to do as I haven't worked out the details of the translation scheme or how to represent Ports in the Click language.

zsnd-basic

Copperbox revision 2458.

I've changed the context so there is a concrete system context for tempo and a parametric user context for instrument specific parameters. The system context will be extended with the staccato_factor from the AdvNotelist.

Update - revision 2459. AdvNotelist now uses staccato_factor from the system context.

zsnd-basic

Copperbox revision 2457.

Work extending the AdvNotelist - I've added a transformer version and made the interface more comparable to the Notelist monad.

zsnd-basic

Copperbox revision 2456.

I've added a new notelist object based on concatenation rather than time-line positioning.

zsnd

Copperbox revision 2455.

I've moved the symbolic pitch modules into a new package zsnd-symbolic, this is will form the analogue to wumpus-drawing.

zsnd-core

Copperbox revision 2454.

Some work tidying the Inst code. I can encode yesterdays experiment with the Inst builder as it is, but I'm still not really satisfied with way of defining instruments. I've been working with a CPS implementation but so far the results aren't especially promising.

zsnd-core

Copperbox revision 2453.

I've added an experiment in designing a new notation for instruments. Rather than define a instrument as a graph within the do-notation, I'm trying to get a more linear definition similar to ChucK. Graph definitions don't really seem composable, whereas a linear definition might be more promising - in Haskell, Lava seems to be an obvious precedent.

zsnd

Copperbox revision 2452.

Minor updates - changed naming scheme of Gen routines in zsnd-core, and removed commented out code in zsnd-basic.

zsnd-basic

Copperbox revision 2451.

I've reworked the Score datatype - it now supports composition (overlay, concatenation).

zsnd-basic

Copperbox revision 2450.

I've added new modules PosEvent, which is PosObject in Wumpus, and Concat. It looks like the current Score datatype will need a rework as currently it is incompatible with the concat type classes.

zsnd-basic

Copperbox revision 2449.

I've added some more of the Wumpus objects - AdvObject, Connector, TraceLoc - and a symbolic pitch type.

I'm not sure whether AdvObject with have a reasonable use-cases for modelling events. Connector might be interesting though - it seems like it could be used for interpolations. TraceLoc might actually be more idiomatic for modelling note lists than TraceNotelist.

zsnd-basic

Copperbox revision 2448.

I've added a module of gen routines - these are the same as the gen routines in ZSnd-Core, but they are lifted to LocEvent so they can be used in the TraceNotelist monad. With this in place, I can now generate scores in the high level language.

zsnd-basic

Copperbox revision 2447.

I've added the TraceNotelist module which is analogue to TraceDrawing in Wumpus-Basic. This provides the Notelist monad - the main monad to build note lists with.

zsnd-basic

Copperbox revision 2446.

I've started a new project zsnd-basic, building a higher level layer on top of zsnd-core. Unlike ZMidi, there is a much better analogue to Wumpus-Basic. The major difference is that there isn't a unified context, cf. the DrawingContext in Wumpus-Basic - instruments are expected to have their own context.

zsnd-core

Copperbox revision 2445.

Various updates to the Inst / orchestra code. I've recreated a more substantial example from the Csound demos (the Zanadu FM synthesizer) which revealed some problems. Some I've fixed - allowing the int pretty printer to print negative numbers and printing floats in decimal notation, but others are more pernicious. As  a quick work around I've added a parens combinator to draw parens in the output code. This could be achieved with a proper unparser for arithmetic expressions that adds parens automatically, but I'm not minded to write one at the moment. The other problem is I seem need transparent casts in the Haskell code:

inst3 :: Inst
inst3 = runInstBuilder 3 $ do 
    ishift        <- ivar 0.00666667
    ipch          <- ivar (cpspch $ pfield 5)
    ioct          <- ivar (octpch $ pfield 5)
    (kadsr::Kr)   <- linseg 0 (pfield 3 / 3) 1.0 
                              [ ((pfield 3 / 3), 1.0), ((pfield 3 / 3), 0)]
    (kmodi::Kr)   <- linseg 0 (pfield 3 / 3) 5 
                              [ ((pfield 3 / 3), 3), ((pfield 3 / 3), 0)]
    (kmodr::Kr)   <- linseg (pfield 6) (pfield 3) (pfield 7) [] 
    a1            <- avar $ castAR $ kmodi*(parens ((kmodr-1)/kmodr))/2
    a1ndx         <- avar $ abs ((a1 * 2) / 20)
    a2            <- avar $ castAR $ kmodi*(parens ((kmodr+1)/kmodr))/2
    a3            <- tablei_ a1ndx 3 1 0 0
    (ao1::Ar)     <- oscil a1 ipch 2
    a4            <- avar $ exp((-0.5) * a3 + ao1)
    ao2           <- oscil (a2 * castAR ipch) ipch 2
    (aoutl::Ar)   <- oscil (1000*(castAR kadsr)*a4) 
                           (ao2 + castAR (cpsoct(ioct+ishift))) 1
    (aoutr::Ar)   <- oscil (1000*(castAR kadsr)*a4) 
                           (ao2 + castAR (cpsoct(ioct-ishift))) 1
    outs [aoutl, aoutr]

I think it will be a good idea to allow instrument definitions in native Csound to be combined with scores in Haskell. Whilst embedding the instrument language in Haskell was an interesting technical challenge, instruments are generally going to be easier to define with Csound rather than Haskell.

zsnd-core

Copperbox revisions 2443 and 2444.

I've added a module for the signal modifier opcodes (envelopes, delays etc.). I'd never noticed before that Csound has nullary opcodes, e.g. delayw, fortunately as opcodes are represented with a list of results, nullary opcodes are just the empty list. 

zsnd-core

Copperbox revision 2442.

Now that I have a rate polymorphic opcode function, I've been able to replace the code duplication where I had to make a class for functions that could return either at AR (audio rate) or KR (control rate) but not IR (init rate).

zsnd-core

Copperbox revision 2441.

I've changed opcode so it is overloaded. The previous version didn't actually work for functions that were totally rate polymorphic as it always generated i-prefixed variables.

zsnd-core

Copperbox revision 2440.

I've split the opcodes into multiple files - there are so many of them that they need their own organization.

zsnd-core

Copperbox revision 2439.

Work implementing opcodes. Unfortunately this is going to be a very laborious task as the tricks to get some static typing in the instrument definitions make the opcode definitions repetitive. And there are a lot of opcodes.

zsnd-core

Copperbox revision 2438.

More gen routines - I've now wrapped all the ones listed in the Csound book. One problem with the Csound book and manual is that they rarely mention whether arguments are integral or floating types - it's quite likely I've made a number of wrong guesses in the types of the Haskell wrapping functions.

zsnd-core

Copperbox revision 2437.

I've added more gen routines and made table number assignment implicit in the monad as numbering is usually sequential from 1. Numbering can be controlled with a setter if necessary.

zscore - now zsnd-core

Copperbox revision 2436.

I've renamed ZScore, it is now ZSnd-Core. If the project grows, it is expected to follow the Wumpus pattern - Core for the code that directly generates output, Basic for a high level layer that is feasible to program with.

zscore

Copperbox revision 2435.

I've added a top-level shim module and renamed the CsoundGens module to GenRoutines. As I've noted previously, the whole project will actually need a new name as it generates both scores and orchestras...

zscore

Copperbox revision 2434.

The Inst example now generates a valid .csd file, which can be run with Csound.

zscore

Copperbox revision 2433.

I've added carry shorthand to the score file output. This should make the generated scores a bit easier to read.

zscore

Copperbox revision 2432.

I've added a typed layer to the Inst language to differentiate signal rates. Plus, I've simplified the Score syntax and added a monadic builder (Writer).

zscore

Copperbox revision 2431.

I've added a module for opcodes. Plus I've decided to generate variable names rather than annotate them directly as Strings, the example from yesterday now becomes:

demo01 :: Doc
demo01 = format $ runInstBuilder 199 $ do
   iamp <- ivar $ pfield 4
   ifrq <- ivar $ cpspch (pfield 5)   
   a1   <- oscil iamp ifrq 1
   out a1

zscore

Copperbox revision 2430.

I've started a new music experiment ZScore to generate Csound - I'll rename it soon as will have the capability to generate both score and orchestra files. Orchestra generation seems to work quite well in the do-notation, with one unfortunate exception - variable names can't be reified, so they must be duplicated as Strings:


demo01 :: Doc
demo01 = runInstBuilder 199 $ do
   iamp <- var "iamp" $ pfield 4
   ifrq <- var "ifrq" $ cpspch (pfield 5)   
   a1   <- oscil "a1" [iamp, ifrq, 1]
   out a1

wumpus-tree

Copperbox revision 2429.

Some tidying up. I'm still not sure how I intended to handle references in Wumpus-Tree, so as a prelude I've tidied up some of rough edges in the code.

wumpus-tree

Copperbox revision 2428.

Initial work adding references to the intermediate tree. This work is intended to replace the current monadic tree building as do-notation is more a hindrance than help for building trees, but I've got a lot of details to work out.

wumpus

Copperbox revision 2427.

I've generalized the RefTrace monad in Wumpus-Drawing so arbitrary connectors can be built, not just unary, binary and multiway (list) ones. This is a prelude to reworking Wumpus-Tree so that it can support references within a drawing. Currently it has monadic building which sort of supports references, but this is pending replacement.

wumpus-drawing

Copperbox revision 2426.

I've added support for upright text - this is text that calculates the vertical size of its orientation rectangle and bounding box from the baseline to the cap height (ignoring the descender depth).

In certain circumstances, accounting for descender depth can produce an ill-balanced drawing when none of the characters in the input string actually have descenders - e.g. drawing numbers within a rectangle frame produces a top heavy drawing as all the digits are the height of caps but none descend. To rectify this, I've extended the API's for PosChar and SimpleText with Up versions of the exported functions. Multi-line text doesn't suffer from this ill-balanced centering, so I haven't needed to extend the DocText API.

wumpus

Copperbox revision 2425.

DocText now has proper underline metrics (i.e. derived from AFM files). I'm not sure that visually the results are any better, but at least they aren't arbitrary.

wumpus-basic

Copperbox revision 2424.

Back to Wumpus as I'm getting nowhere with ZMidi...

I've added underline position and underline thickness to the metrics I extract from font files. This is so I can improve the underline handling for DocText in Wumpus-Drawing.

zmidi-basic

Copperbox revision 2423.

I've put rests back into the syntax and added a toy module experimenting with beat pattern construction. Unfortunately, the real work work has largely run into the sand - I've actually coded very similar beat pattern construction before but never found it pleasant to program with, and the objects that are nice to program with in Wumpus don't seem to have analogues for music after all.

As noted yesterday, building music isn't especially positional compared to graphics. Instead, musically objects seem more like strings that get combined and permuted then expanded (rendered) by adding more information to them - e.g. beats patterns are just strings of beat lengths that get zipped with strings of pitches to produce an output stream of notes. But this string view, whilst compact for the places where it works, often doesn't work - beat patterns can't handle triplets or half note subdivision and pitch sets can't handle accidental pitch changes outside the tones of the current scale. So I'm stuck at the same place that I was with Neume and Bala when I decided to punt them into the long grass and work on Wumpus.

zmidi-basic

Copperbox revision 2422.

More foundational work. I've got the first object in place Event which is the analogue of Image in Wumpus-Basic. Because representing music has more structure (syntax) than graphics, the work is rather tentative and may be heavily revised.

For graphics superimposition is perfectly fine - graphics can be stacked on top of each other and the renderer uses the "painter's algorithm" or similar to draw only what is on top. My feeling is that superimposition would work for music if my primitive composition was additive synthesis (this would be equivalent to rendering with transparency rather than strictly the painter's algorithm), but as I'm composing MIDI I have to be more careful about overlapping.

For MIDI, I solve overlapping by adding overlays and voices to the intermediate syntax. This extra syntax gives me the ability to be fairly careful about contention for note-on note-offs, but having more syntax naturally makes it more complicated to actually build music - it stops me writing an `at` combinator that enjoys the (near) universality it enjoys in Wumpus.