om-shell

Copperbox revision 2923.

I've added a pitch shifting processor, unfortunately it seems rather uncontrollable.

om-shell and ochre

Copperbox revision 2922.

I've added a tremolo processor to OM-Shell. It is written in a slightly more "functional" style - i.e. the body of the processor is a function from signal to signal. Maybe this is a valid direction for defining instruments (processors) but the code actually isn't much shorter.

Ochre - I've fixed a very silly bug where I was using flip in Haskell for functions that built expression syntax in Ochre. Particularly, I was flipping the arguments for division, but division is not commutative so this was nonsensical.

om-shell

Copperbox revision 2921.

I've updated all the instruments and demos to work with the envelope changes in Ochre and Majalan.

majalan

Copperbox revision 2920.

I've replaced the Fence Post List with an Envelope data type as per Ochre. The Fence Post List was a bit over-engineered.

ochre

Copperbox revision 2919.

I've moved the envelope data types into their own module and made them less polymorphic - the size unit is now fixed to an IFloat for durations.

This is because I want to remove the Fence Post List data type from Majalan and replace it with another envelope data type where the size unit is fixed to Int for array index / table size. I could share the envelopes in Ochre if I kept them polymorphic, but I don't want Majalan to depend on Ochre.

om-shell

Copperbox revision 2917.

I've added the compressor instrument from chapter 30 of the Csound book. Potentially I have a bug due to amplitude calculation and using 0dbfs... if I don't then it is another sonically boring processor.

Copperbox revision 2918 - I had a bug.

om-shell

Copperbox revision 2916.

I've added delay and reverb processors. Unfortunately both are a bit boring sonically.

om-shell and ochre

Copperbox revision 2915.

OM-Shell - I've added a babo (ball in a box) reverb signal processor. This is quite exciting as it finally turns the FM gong into an attractive sound, if perhaps a bit watery.


Ochre - I've fixed a missing case for SigDef2 in the monadic translation and added babo as an opcode.

om-shell

Copperbox revision 2914.

I've updated the the instruments and examples to use Zak ports so they can be chained with effects processors (though currently I only have a wahwah effect).

om-shell

Copperbox revision 2913.

I've updated the om-shell code to work with the changes to Majalan. Hopefully code in om-shell should now start to become more idiomatic.

majalan

Copperbox revision 2912.

I've changed the unified file (aka *.csd) building to use a writer monad rather than build a CsDoc directly. This means I have a bit more flexibility in using white space and I've also add some phantom typing to make the CsDoc building a bit more structured.

majalan

Copperbox revision 2911.

I've simplified rendering Event Lists (scores) to Docs. Particularly the internal types are now a bit simpler as I don't represent carry as a value - carried values are printed straight away, the separate translation step to low-level values has been eliminated.

om-shell

Copperbox revision 2910.

I've added two new FM instruments - versions of the bell and drum from the Common Lisp Music distribution.

om-shell

Copperbox revision 2909.

I've now got the Zak FM gong to work in an effects chain with a wah-wah pedal.

omshell, ochre

Copperbox revision 2908.

I've added some initial Zak instruments with the intention of building effects chains. Also I've removed the liftGens function in Ochre - this function should be unnecessary.

omshell, ochre

Copperbox revision 2907.

I've updated the FM gong to use the do-notation / statement style. Notationally there seems to be an improvement.

ochre

Copperbox revision 2906.

I've fixed the error, observed yesterday, in the translation from embedded monadic code to the compiler's expression language.

ochre

Copperbox revision 2905.

I've changed the syntax of the embedded DSL to be statement oriented rather than expression oriented.

With expressions, I found that I couldn't get tuples "for free" - I would have had to embed them in the DSL even though they can't feature in the final code (Csound has no tuples). With a statement based language I can get more from Haskell's do-notation.

The compiler remains the same - instruments are still first-order expressions, but there is an additional translation step from the embedded language to the compiler's internal syntax. Currently the translation has errors and the 2 more complicated instruments in the demo don't compile.

ochre

Copperbox revision 2904.

I've added global level opcode invocation, so initialization of global variables (via init) and zakinit are now supported.

zmidi-core - new release 0.6.0

Copperbox revision 2903.

I've made a new release of zmidi-core for Hackage - version 0.6.0. This release extends the parser to be able to handle files encoded with running status - previously if running status was set, the parser saw voice events as uninterpreted data.

zmidi-core

Copperbox revision 2902.

I've added a module ZMidi.Core.Canonical to fully expand a syntax tree that uses Running Status. In practice the parser has already expanded Running Status so all the canonical translation needs to do is change Running Status On - NoteOn events with channel velocity 0 to NoteOff events.

zmidi-core

Copperbox revision 2901.

I've made the parser error tolerant when it is out-of-step with Running Status data - yesterday it was throwing a fatal error at this point in the code. Some of the code has been tidied up, although the documentation needs improvement before it is released on Hackage.

zmidi-core

Copperbox revision 2900.

Running Status support now appears to be implemented - a pattern match case that throws an error needs improving and the code needs proper testing.

zmidi-core

Copperbox revision 2899.

Initial work on supporting Running Status. This is mostly pertinent to the parser, though the syntax and writer have been modified. The parser doesn't work at the moment... 

zmidi-core

Copperbox revision 2898.

I've added a hack to the pretty printer than stops high ASCII chars (164 and above) causing a runtime error when trying to print them to stdout. The hack simply rewrites the string changing chars greater than 163 to #.

ochre

Copperbox revisions 2896 and 2897.

I've changed the module hierarchy - the Phantom folder is now called Language. This is a more neutral name so code for building orchestras (which makes no use of phantom types) can go alongside the code for building instruments (which does use phantom types).

ochre

Copperbox revision 2895.

Work towards global statements for init, zakinit, etc. Most of the code is in place, but I'm not too keen on the module organization.

ochre

Copperbox revision 2894.

I've changed the envelope representation so it works list a snoc-list, previously it was a Hughes list built with mappend.

ochre and om-shell

Copperbox revision 2893.

I've added functions in the style of the vector-space library to "scalar multiply" a signal by and I-rate constant (or add an I-rate constant, or divide by one). Using these new operators has increase the succinctness of the FM gong instrument.

ochre

Copperbox revision 2892.

I've fixed identical bugs in alpha conversion and beta reduction where compound values (like BinOp and RelOp) were not being properly traversed.

ochre

Copperbox revision 2891.

Redundant variable elimination now working. Redundant variables are eliminated by constant folding, beta reduction and let-elimination working in concert.

ochre

Copperbox revision 2890.

I've fixed yesterday's bug which turned out to be a problem with Alpha renaming. This has revealed that constant folding is not as aggressive as it should be, on we go...

ochre

Copperbox revision 2889.

Ochre needs the Assoc compiler pass which linearizes nested LetSig definitions, Id' taken it out for a while mistakenly thinking it didn't. Unfortunately it is somehow not working...

ochre and om-shell

Copperbox revision 2888.

I've changed the letSig family of functions to lower case letsig. This is entirely cosmetic but having camel case keywords in the the embedded language seemed horrible when I thought about it. updateSig will need changing too, but I'm stuck for a better name...

new release - zmidi-core-0.5.0

Copperbox revision 2887.

I've made a new release of zmidi-core for Hackage. This improves the Haddock documentation, an reorders the constructors of the MidiVoiceEvent constructors so the follow the order of the tag bit in binary MIDI files.

zmidi-core

Copperbox revision 2886.

I've improved the Haddock docs for zmidi-core - when I last built them all modules reported 100% doc coverage.

zmidi-core

Copperbox revision 2885.

Work on improving the parser.

Some of the changes are a bit gratuitous so I will have to test them tomorrow, but they do make the code cleaner and they make it clear that MidiVoiceEvent, MidiSysCommonEvent and MidiSysRealTimeEvent don't need fallback constructors. MidiMetaEvent needs a fallback constructor (MetaOther) as not all possible meta events are enumerated; but MidiVoiceEvent etc. are fully enumerated - if the parser has a pattern match failure for these productions it means that the code is wrong elsewhere.

new release - zmidi-core-0.4.0

Copperbox revision 2884.

I've put a new release of zmidi-core on Hackage - version 0.4.0.

This has better handling of "unrecognised" Meta events in the parser, plus a new Meta Event MidiPort. I think VoiceEvent should probably have a similar "unrecognised" catch all constructor so there might be another release at the weekend.

zmidi-core

Copperbox revision 2882.

I've reactivated zmidi-core to look at the robustness of the parser. Currently it throws errors in some places where it could easily recover. It would be nice if MIDI event "packets" carried their length "on the outside" - this would make it easy to tolerate errors (chunk the input as per size, parse the chucks, flag up what fails to parse); unfortunately packet size is dependent on knowing something about the event so I doubt I can make the current parser fully tolerant.


Copperbox revision 2883.

Added MidiPort meta event.

om-shell and ochre

Copperbox revision 2881.

The FM gong example now works. It has signal update (reusing variables), envelopes and I-rate declarations - so this is quite an advance.

ochre

Copperbox revision 2880.

I've implemented "top level" I-rate variable declaration to instruments. The syntax for this was added last week, but I forgot to implement it in the builder code. I've also started to look at encapsulating "envelopes" in a separate type, though this half-baked at the moment.

ochre

Copperbox revision 2879.

I've added error handling to the Orch monad. Signal dereferencing can (unfortunately) generate run time errors rather than type errors, so I'm trapping bad cases in the monad rather using error.
 

ochre

Copperbox revision 2878.

I've implemented safer casting for signals - signals can only be upsampled rather than downsampled. New shorthand operators for casting combination of signals (addition, multiplication...) have been added to alleviate some of the syntactic burden of typing signals with their rates (audio, control, init).

ochre

Copperbox revision 2877.

I've renamed PExpr to InstCode and removed the synonym M. This is to remove the emphasis that instrument bodies are expressions and to stop the association where effectful code was monad-like. As InstCode is not a functor let alone a monad, it seemed a bad idea to pun between monads and effects.

ochre

Copperbox revision 2876.

I've changed the opcode wrappers so they can compile again. The next step is to see how the Phantom layer can be simplified again.

ochre

Copperbox revision 2875.

I've started simplifying the phantom type layer. Initially I'm making PValue simpler as it shouldn't need variable supply. When I've checked this I'll go back and look at the naming schemes.

Currently the DemoMon example doesn't compile - changing the phantom types cascades changes to dozens of opcode wrappers, which are outstanding.

ochre

Copperbox revision 2874.

I've renamed the compiler monad from Mon to Compiler. This is a prelude to changing the phantom type layer where I may want a monad (if I do Mon will be a good name). I don't think values need name supply in the phantom layer, if so then I should be able to simplify it quite a bit.

ochre

Copperbox revision 2873.

I've added signal update and immutable top-level declarations that can't be let-eliminated or constant folded. The former allows the Csound optimization of minimizing variable declarations, the latter allows more readable generated code as i-rate declarations can be preserved.

Both implementations are hacks as I envisaged implementing them differently when I started designing Ochre. I'll probably have to rethink the Phantom layer somewhat as Signals now have a specific meaning to Ochre which the old code in the Phantom layer doesn't properly respect.

ochre

Copperbox revision 2872.

Work on ref-cells so I can implement the FM gong I wrote in Csound last year. Unfortunately the current design of ref-cells looks like a dead end and the code in this commit needs a rethink.

ochre

Copperbox revision 2871.

I've improved the phantom type layer - user code was mandating type annotations that I didn't expect.

Also I've fixed a bug printing floats - unfortunately Wumpus has this too.

ochre

Copperbox revision 2870.

I've added pure let - previously I just had effectful let, but it wasn't named as such. I've also added effectful let for 2,3 and 4 tuples. The introduction form is actually more like Scheme's let-values than proper tuples - Csound doesn't have tuples itself so I have to be very careful about their introduction and elimination in the embedded language.

majalan & om-shell

Copperbox revision 2869.

Minor updates to Majalan - as I wrote a lot of code before I had demos / tests, quite a few errors have crept in. I've corrected some now.

I've added a new module to OM-shell for Doc builders that depend on Majalan and Ochre. I don't want Majalan to depend on Ochre, so they have to be implemented here. 

om-shell

Copperbox revision 2868.

New package om-shell to help work with Ochre and Majalan at the GHCi prompt. The demo is the first time I've had Majalan and Ochre working together.

ochre

Copperbox revision 2867.

I've reworked Ochre's API so that global variables are now bound using the do-notation. I've also reduced client imports to a single top-level module.

majalan

Copperbox revision 2866.

Work on improving the API of Majalan. Some of the changes are quite gratuitous - e.g. wrapping lists and using monoidal concat to make the specification of column headers and widths less cryptic rather than using lists of pairs.

I've started using Majalan and Ochre together so hopefully they should both start improving.

majalan

Copperbox revision 2865.

I've refactored the EventM class to allow up to four time varying behaviours. Probably I should go up to fourteen or so, but as I don't have any instruments defined yet four will do for now.

majalan

Copperbox revision 2864.

I've added Wumpus style parametric time units. The implementation is the same as Wumpus, but because the primitive event operations are simpler in Majalan than images are in Wumpus, I think it will be easier to program with. At some point the programming style could be adopted by Wumpus.

majalan

Copperbox revision 2863.

I've added an introspective TimeSpan to the event list monad (where TimeSpan works like a bounding box). This allows events to depend on the time span of previous event - e.g. setting up a delay processor to work on another instrument.

majalan

Copperbox revision 2862.

I've added more Behavior combinators and defined more class instances for Behavior following the example in Paul Hudak's SOE.

majalan

Copperbox revision 2861.

I've added behaviours in the style of Paul Hudak's FAL (and thus Conal Elliott's Fran?). This feels like a big step that will add a lot of expressive power to Majalan - it's the first time I've ever managed to incorporate FRP style programming into one of my own projects, fourteen years (I think) after being totally beguiled by the FRP animations in Conal's Dr Dobbs Journal article.

majalan

Copperbox revision 2859.

Work towards interpolating "columns" in event lists. The idea was to have parametrize the Event type so it could have a payload as either a normal list of params or a function from an interpolating value to a list of params - but I don't think this is practical. I suspect using a symbolic number type and overloading the Num classes will be simpler.

Copperbox revision 2860.

I've reverted the interpolation changes from the last commit, but kept in the changes that implement advancing c.f advance vectors in computer typesetting and Csound's (+) symbol in score files.

majalan

Copperbox revision 2858.

I've added a few more GEN routines. The only one that is interesting from an embedding perspective is GEN11 which has optional arguments. I've chosen to require all arguments - the documentation lists the default values.

Optional arguments are more heinous in orchestras than scores, where there are fewer primitives that make use of them. As this is the only occurrence I've found so far, requiring all which doesn't restrict expressiveness seems the best solution.

majalan

Copperbox revision 2857.

I've added a couple more GENs - GEN01 which loads a file and GEN02 which stores user supplied data.

GEN01 particularly is an interesting case - should Majalan imitate Csound (e.g. use numeric enums rather than enum types) or provide a higher level (but not idiomatic) API? At the moment imitating Csound seems a better choice as GENs are usually invoked only a few times in a score and following the Csound means its documentation is mostly appropriate.

majalan

Copperbox revision 2856.

I've split Gen into two modules - one for the primitive functions and types and the other for the catalogue of table-gens matching Csounds GEN functions. Also I've changed gen07 to use a fence list.

majalan

Copperbox revision 2855.

The demo now emits a valid Csound csd file.

As I hadn't tested the output before, there were quite a lot of minor errors in the pretty printing (wrong argument orders, floats that should be ints...). Hopefully these are all found and fixed.

majalan

Copperbox revision 2854.

I've changed the Event type so it is a function from start x duration to an opaque event object. This makes it syntactically similar to the latest Gen representation. 

majalan

Copperbox revision 2853.

I've made Gen tables a newtype wrapping a constructor function. This gives a useful distinction between their definition (the values for envelope shape or whatever) and their instantiation (size, index number for instrument and activation time).

Again the type is still opaque - there is no introspection only construction.

majalan

Copperbox revision 2852.

I've changed f-tables (gens) making them opaque commands rather than functions that return an introspective GenTable.

There doesn't seem to be much of a need for introspective GenTable object, as it doesn't seem to support useful manipulation (there isn't a reasonable way to halve or double the resolution of tables, though there can be for specific table instances). So it seems better to have a command to write table instantiation in the score.

majalan

Copperbox revision 2851.

I've added Writer monad style event list building to the Event module. This means more of the implementation can be hidden, which should allow some tidying up.

majalan

Copperbox revision 2850.

I've added a module IncDoc that wraps HughesPJ's Doc and allows textual inclusion of whole files. This means Majalan can use predefined orchestras or the output from Ochre.

majalan

Copperbox revision 2849.

I've reworked the Event module so it can make good, nicely formatted event lists - sorted and printed with columns and carry (dot in Csound).

majalan

Copperbox revision 2848.

I've restarted work on Majalan (more accurately I'm starting afresh but keeping the name). The idea is less to make an EDSL score language than to make a kit which composition / instrument specific score languages can be made from.

All the previous code has been thrown out - I'm usually reticent to garbage collect Copperbox, but really I ought to do this more.

ochre

Copperbox revision 2847.

I've reworked the phantom type layer to appear simpler and more idiomatic. In truth the implementation is a bit of a sleight of hand to make the types seem more conventional than they are, but for now I am happy with it.

ochre

Copperbox revision 2846.

I've added another couple of granular synthesis opcodes. The types of the phantom type layer really need revising as they are too cryptic - fortunately I have tomorrow off as a holiday to do this.

ochre

Copperbox revision 2845.

I've added two fof granular synthesis opcodes and a little bit more Haddock documentation.

ochre

Copperbox revision 2844.

I've added Haddock docs and improved the types of the Zak opcodes.

Intentionally I've made the API a bit more restrictive than the Csound one. In Csound it seems like you can change Zak ports at k-rate, but idiomatic code never does this so I've ruled it out.

ochre

Copperbox revision 2843.

I've filled out the translation to Csound - currently there are no incomplete pattern matches. By necessity there are plenty of error throws that catch bad syntax, hopefully it is hard to create bad syntax in the first place.

Now I'll have to polish up the opcodes and start writing examples...

ochre

Copperbox revision 2842.

I've split the Csound module into separate modules for syntax and translation. This means I can keep the syntax code tidy whilst working out the translation and I don't get overwhelmed by compiler warnings.

ochre

Copperbox revision 2841.

Some work on the translation to Csound. A lot of work still needs to be done on this - it has always been incomplete, plus it wasn't really updated when the division between expressions and values was extended making functions, binary applications etc. as values rather expressions.

ochre

Copperbox revision 2840.

I've changed to monad state to count according to rate so you get a1, a2, i1, i2, k1 rather than a1, a2, i3, i4, k5. This makes the generated code a bit more idiomatic.

ochre

Copperbox revision 2839.

I've added phantom opcodes for zak patching. This has indicated that the current "type system" provided by the phantom types is not accurate (nor is it systematic, but that's another matter). It will need a re-think...

ochre

Copperbox revision 2838.

I've extended constant folding to all the (effectful) expression constructors. Previously the multiple binding constructors Let2, Let3, Let4 were not handled.

ochre

Copperbox revision 2837.

I've improved constant folding. The code is now a bit more repetitive, but it is otherwise nicer - the previous code wasn't so clever even though it tried to be. 

ochre

Copperbox revision 2836.

I've changed the syntax so it has a constructor for relational expressions. Previously the cond part of if-then-else had 3 values for relational operator and left and right values, this was to stop instances like the following:

if 1 then true-stmts else false-stmts

Seemingly this is invalid Csound which apparently only supports genuine conditional expressions in the cond part, so the previous syntax enforced three part cond expressions. However it was difficult to work with this in practice and we should either be able to eliminated the conditional altogether by constant folding or translate it to a proper conditional during the final translation.

Note - constant folding has been disabled in order to get the current code to compile.

ochre

Copperbox revision 2835.

instr101 in DemoMon is now compiling again. Plus I've removed some of the cruft in Prim.hs (there is still more to go...)

ochre

Copperbox revision 2824.

I've changed the internal syntax to use two-level syntax - effectful expressions and pure values - from the start.

Previously, the initial syntax was a single expression type that was transformed into K Normal form but this put a lot of typing burden on the compiler and prevented me having ugens polymorphic on signal rate. Also the phantom typed layer essentially built two-level expressions anyway.

ochre

Copperbox revision 2833.

I've eliminated the bug discovered yesterday where constants (pfields) were getting replaced by unassigned var-ids. I don't really understand why this was happening, but changing the compiler runs so it resets the var counter for each instrument eliminates the error.

ochre

Copperbox revision 2832.

I've added pfields to the phantom syntax.

This seems to have revealed a bug in the translation from K-normal form to Csound where the (pure) binding of the pfield to a variable gets discarded. I'll have to fix the bug tomorrow...

ochre

Copperbox revision 2831.

I've added sequencing to the the top level syntax and to the K-normal form syntax.

ochre

Copperbox revision 2830.

I've redesigned the phantom type layer in Ochre so it works the same as Wumpus-Expr.

As a side-effect I've coined my own alternative to the do-notation for handling effects. Ideally I would have used the do-notation but I need to reify pure let-binding as well as monadic binding. Interestingly Csound instruments more-or-less have their own do-notation separating pure expressions and effects - pure expressions bind with equals, effects bind with calls to opcodes which are just missing (<-)  in the syntax.

wumpus-afm-loader

Copperbox revision 2829.

Work on a font metrics loader to eventually replace the one in Wumpus-Basic.

I was hoping to use a Perm parser to parse global font information, but unfortunately whilst Perm parsers accept "any order" they (seemingly) need to be able to recognize all attributes. This doesn't fit my purpose - I only want a small subset of the attributes - so I have to use a pre-processing step instead. The current implementation messes up line numbers.

wumpus

Copperbox revision 2828.

Updates to wumpus-basic and wumpus-drawing to accommodate the change in wumpus-core to AfmUnit.

wumpus-core

Copperbox revision 2827.

I've changed AfmUnit to wrap Int rather than Double. AFM files don't have fractional values so AfmUnit should be an integer type.

wumpus-core

Copperbox revision 2826.

I've added primitive move-to operations for building paths. This means path building can now automatically exploit PostScript's non-zero winding number drawing rule to produce complex path fills.

krayola

Copperbox revision 2825.

Initial work on a Haskell based glyph drawer - ft_props.

For some reason, certain characters in the system Arial font draws poorly with ft_outline (lower case 's' is one). So I can visually debug what is going wrong I'm writing a Haskell based glyph renderer where I can use Wumpus for the drawing. This should help me make more illustrative pictures of the outline than I could by generating PostScript from C as Wumpus has built-ins for illustrating Bezier curves etc.

krayola

Copperbox revision 2824.

Using the advance vector to print a string of multiple glyphs in the ft_outline doodle.

krayola

Copperbox revision 2823.

Work on a FreeType doodle that draws the outlines of glyphs in PostScript.

I've been thinking that OpenVG is a better fit for Krayola than OpenGL, but OpenVG has no support for text. This is a show stopper, but potentially FreeType is capable - after all it is used by FTGL and oglft to render text to texture maps.

For the time being, whilst I get familiar with FreeType, generating PostScript is more convenient than working with OpenVG.

OpenVG binding

Copperbox revision 2822.

I've updated the OpenVG binding - both "Raw" and the high level layer - to build without errors.

krayola

Copperbox revision 2821.

Added a stroked polygon drawing doodle.

There is a lot to attend to when using OpenGL to draw 2D. I'm almost surprised Processing uses OpenGL as its basis for drawing but perhaps there wasn't much choice at the end of the nineties. Actually I'm not sure there is much choice now as OpenVG seems like a white elephant.

krayola

Copperbox revision 2820.

I've added my first OpenGL in C doodle.

It's a bit of a mea culpa, but I've never actually written any OpenGL of my own. I've compiled and not compiled (due to makefile frustrations) various examples and I've got four of the Addison Wesley books, the first I got something like 14 years ago; but I've never worked anything out for myself. It's time to start.

wumpus-expr

Copperbox revision 2819.

I've added function definition and application to the TopLevel syntax layer. This means you can now embed functions "properly" [*] in Wumpus-Expr, although you can't compile them yet as the translator needs extending.

[*] Properly embedding functions in Wumpus-Expr means they are defined as-is in the target language rather than inlined into a huge expression. This is important as Wumpus-Expr has function definitions specifically to reduce code size.

OpenGL version number

Here's a program to print the OpenGL version to the console:

#include <GL/gl.h>
#include <GL/glut.h>

#include <stdio.h>

static GLint window;

int main( int argc, char* argv[] )
{

  char *gl_vers;
  

  glutInit(&argc, argv);
  glutInitDisplayMode( GLUT_SINGLE | GLUT_RGB );
  glutInitWindowSize(500, 500);
  window = glutCreateWindow( "Need a window to get the version.");

  gl_vers = (char *) glGetString(GL_VERSION);

  fprintf(stdout, "GL version:\n");

  if (gl_vers != NULL)
    fprintf(stdout, "%s\n", gl_vers);

  return 0;
}

Apparently my GL version under MinGW is 1.1.0 - disappointingly old skool!

wumpus-expr

Copperbox revision 2818.

Work on the phantom typed top level. Adding phantom constructors and operators for most of the constructors of the Expr datatype - only application and return are outstanding. Return is probably unnecessary, application needs some thought as it is n-ary in Wumpus-Expr unlike Haskell where it is binary.

wumpus-expr

Copperbox revision 2817.

Initial work on a phantom typed top level layer. The work is a bit wacky as it hides monadic code in newtype wrappers to give it type signatures that look pure (nothing unsafe though). Although I haven't tested it yet, I think it improves the design in Ochre which tried to do similar.

wumpus-expr

Copperbox revision 2816.

Following the experiments with the CPS-mon code, I've made the expression language in Wumpus-Expr monadic.

As Wumpus-Expr doesn't have a lambda form, I only have (>>) monadic sequence and not (>>=) monadic bind. Maybe this will be a problem, maybe it won't - I'll have to work out the consequences.

Off-topic - I've been looking at SDL for graphics and simple user-interfaces, hence no commits the last two days. SDL is interesting but very low-level - it would need a lot of work to functionalize it.

cps-mon

Copperbox revision 2815.

I've finished the CPS transformation and added pretty printers for the source and target languages.

cps-mon

Copperbox revision 2814.

Work on implementing the CPS transformation presented in "How to CPS Transform a Monad" by Annette Bieniusa and Peter Thiemann.

I'm a bit concerned that Wumpus-Expr allows effects in the wrong places - i.e. the heads of let expressions - that will cause problems for the translation from K Normal form to PostScript or JavaScript; so, I'm looking at the expression language in the above paper for guidance as to properly integrating monadic effects.

wumpus-expr

Copperbox revision 2813.

I've re-implemented constant folding. The code isn't significantly neater but it is more complete.

wumpus-expr

Copperbox revision 2812.

I've changed the K Normal form representation to make constant folding inside If expressions easier. Currently the actual constant folding code is stubbed out, tomorrow's work is to re-implement it and see if it is easier...

wumpus-expr

Copperbox revision 2811.

I've extended the interpreter to handle fundefs and funcalls.

Effects in the expression language have been left unchanged, I was thinking Blank Canvas wrapped updates to the graphics state in a local function as per the Reader monad - this isn't the case. While this behaviour would be desirable for Wumpus-Expr it would introduce a risk of entombing graphics state updates in a chain of gsave / grestore that is too deep for PostScript.

wumpus-expr

Copperbox revision 2810.

More work on the interpreter, excepting function defs it now evaluates the expression datatype and produces a bounding box.

As the expression datatype has unrestrained effects there is a lot of potential for the interpreter to be wrong. I think an alternative direction might be to change the expression type so it is more operational like Andy Gill's Blank Canvas. This would make it easier to trust the interpreter. The potential downside is that this makes the embedded language less like PostScript / JavaScript.

wumpus-expr

Copperbox revision 2809.

More work on the interpreter module, the code is a long way from being complete...

I've changed the Program type to have a main function an auxiliary definitions - it should have been defined like this from the beginning as a program must always have a main.

wumpus-expr

Copperbox revision 2808.

Initial work on a interpreter for programs in Wumpus-Expr. The interpreter should produce the bounding box that a drawing (Wumpus program) inhabits.

The code so far is the initial thoughts - already I've seen that the monad is not sufficient and needs at least a Reader and probably a Writer.

wumpus-expr

Copperbox revision 2807.

I've changed VarIds to accommodate immutable prim names (for functions or built ins). This makes the alpha renaming code more stable as it won't change function names.

wumpus-expr

Copperbox revision 2806.

I've added a PostScript symbol constructor to the expression type. Although I don't think PostScript has symbols a la Lisp, it does have opaque defs for font names - this is the use-case that the symbols will model.

Otherwise, I've come a bit unstuck with alpha renaming and VarId's. The current code represents function names with a PrimId that is oblivious to alpha renaming, but the expression syntax doesn't allow me to access a PrimId when it is needed for application.

wumpus-expr

Copperbox revision 2805.

Some work (not much) on the K-normal form to JavaScript translation.

A realization I had whilst committing is that I think I'll need different translators for procs and functions - procs have effects (writing output commands) and can only return Unit, functions should be pure. There's a caveat to this that generating PostScript will be easier if I can live with just procs and no functions...

wumpus-expr

Copperbox revision 2804.

I've extended the JavaScript output syntax and pretty printer to accommodate more of the constructions in the input language.

Side note - I've now managed a contiguous month of "a commit a day", it might be the first time I've achieved this since I've been contracting (some of the commits like today's have been pretty trivial, but I'll let that slide). Unfortunately all my projects are now pending design work - this is something I can't seem to fit in on a work night, so "a commit a day" might end here.

Also I'm not going to buy Max MSP at the moment, so although my work rate is set to drop the work will continue in Haskell. I may buy Max MSP in the autumn.

wumpus-expr

Copperbox revision 2803.

Initial work on PostScript generation. So far, the work has been on the AST and pretty printing, I haven't looked a translation from K normal form, however the AST is a bit more worked out than the JavaScript AST.

wumpus-expr

Copperbox revision 2802.

I've implemented a trivial and incomplete translation of the knormal form representation into JavaScript - only two expression cases are handled Command and Seq others cause a pattern match failure.

pretty-expr-hpj

Copperbox revision 2801.

Work on the C99 and JavaScript expression pretty printers. I've now implemented all the operators except for the mixfix (distfix?) ones like array access and conditional expressions. Currently, these can't be encoded in pretty-epxr-hpj which only handles prefix, postfix and binary expressions.

wumpus-expr

Copperbox revision 2800.

I've moved the JavaScript expression pretty printer into pretty-expr-hpj - a better place for it.

wumpus-expr

Copperbox revision 2799.

Initial work on the syntax tree and pretty printer for the JavaScript backend.

wumpus-expr

Copperbox revision 2798.

I've changed the exports of the optimization functions so they work on programs rather than expressions.

I hope "compilation" of Wumpus-Expr should be fairly easy as the language is first-order rather than higher order. A program is just a list of function definitions.

wumpus-expr

Copperbox revision 2797.

I've added more output commands.

Canvas appears to take many of its command from PostScript, the biggest difference seems to be with the graphic state update commands - line size and end appear as good as the same, but dash pattern and colours are different enough to cause problems. I'll have to think about how to handle them.

wumpus-expr

Copperbox revision 2796.

Started on wumpus-expr - this is an experimental project that aims to support function definition in the generated PostScript or HTML canvas + JavaScript.

Allowing limited function / procedure definition in the target language is the only way to avoid code size explosion in the output from Wumpus. If wumpus-expr is a success, it will form the backend for WumpusLite.

The initial code has taken the K Normal Form compiler from Ochre and changed the syntax to suit graphics generation rather than Csound instruments.

wumpus-lite

Copperbox revision 2795.

Initial work on a new AFM parser.

This time round it doesn't seem necessary to define my own parser combinators - I did this for Wumpus-Basic as the platform shipped with Parsec 2 at the time. Now it ships with Parsec 3, I don't mind the dependency.

wumpus-lite

Copperbox revision 2794.

I've added the BoundingBox module from Wumpus-Core.

lirio

Copperbox revision 2793.

I've added a demo that generates percussion notation. It uses an experimental way of simulating LilyPond's variable def and use that perhaps is not worth the trouble.

lirio

Copperbox revision 2792.

I've removed the parametric user state from the Score and note-list monads. Previously I'd thought this generality would be worthwhile to add bar numbering for example, but simplifying the type signatures seems a better plan.

lirio

Copperbox revision 2791.

Work towards implementing note list operations and marks like the \times command. This has meant some rethinking of the primitive doc code, which now use a more comprehensive naming scheme to avoid needing qualified import.

lirio

Copperbox revision 2790.

I've added a full set of pitch names and changed the naming scheme so that clashes with Haskell variables in user code are less likely.

lirio

Copperbox revision 2789.

I've reworked the note lists to use more overloading and changed their internals so they wrap one of two primitive note lists - one for relative duration and the other for absolute duration. By wrapping one of these, note lists can get most of their type class instances from lifting the appropriate operations on the primitive note list, usually only NoteM and ChordM need implementing "longhand".

Quite a bit of code still needs tidying up...

lirio

Copperbox revision 2788.

Initial work adding overloading for the "doc builder" primitives of note lists. Easy things like spacer and rest have been implemented, note and chord should be doable with type families (or fundeps).

lirio

Copperbox revision 2787.

I've added a directory Base for the primitive data types and functions. This makes the organization a bit more manageable before I look at type classes for the various note lists.

lirio

Copperbox revision 2786.

Initial work on lyrics in the lyricmode style - i.e. syllables with duration annotations.

When I have more time, I'll have to look at overloading for the note list representations - I need quite a few different note list types and qualified imports aren't adequate.

lirio

Copperbox revision 2785.

I've simplified the internal Glyph / Doc type so everything supports suffixing (suffixing is necessary for beams and slurs). Whilst this means Lirio performs less checking - there is more opportunity to make bad syntax, the implementation is now more obvious. There is no longer a mystery about what is a note and what is a glyph.

lirio

Copperbox revision 2784.

I've defined the full set of drum pitch names and the short versions. Again this was rote work, so it was quite easy to keep the "a commit every day" momentum.

ochre

Copperbox revision 2783.

Work on signal IO opcodes. I've also done a small amount of work on making the phantom layer more polymorphic - though I'll have to postpone this until I can work on it at a weekend when I have more time. I've managed a commit a day over the last week, for the first time in ages; if I tackle something that needs "design" this will lose my momentum.

ochre

Copperbox revision 2782.

I've started work on wrapping the signal input and output opcodes and added a top level shim module to make importing the phantom layer more convenient.

ochre

Copperbox revision 2781.

All the signal modifier opcodes are now wrapped in the phantom layer.

ochre

Copperbox revision 2780.

I've added List to the type representation and made tuples heterogeneous so I can model Csound's C-style arg lists - the calling convention for Csound opcodes is like C but Ochre can now encodes variadic functions as lists. As nothing really uses source language types within Ochre (save temporary variable generation), having polymorphic lists and tuples doesn't add complexity.

Also I've made a start on signal modifiers.

ochre

Copperbox revision 2779.

I've completed the signal modifier opcodes and filled out the monomorphic tuple types in Phantom.Prim.

ochre

Copperbox revision 2778.

I've solved yesterday's problem with typing Ints that represent table nums etc. by differentiating between initialization time Floats and Ints in the phantom type layer. I should have done this all along...

ochre

Copperbox revision 2777.

First round of work coding the signal modifier built-ins.

Another nit with the type system - I don't properly handle that Ints could be actually ints or variables / pfields representing ints. This is another bit where embedding in Haskell has allowed me to shirk some duty I have to developing a sound type system. If I had designed a closed DSL, I would have been forced to address this short-coming much sooner.

ochre

Copperbox revision 2776.

I've implemented the base opcodes - base is an arbitrary grouping that I happened to use for Ochre's predecessor Orchsyn, basically they are the Math opertations on pages 704 and 705 of the Csound book.

Implementing these opcodes has flagged up some problems in Ochre's type system. Ochre should really be monomorphic, though it is a bit tricksy as it doesn't have a type dictionary - opcodes can cheat and have different typings according to how they are used in the host language Haskell (as the embedding of Ochre borrows some of Haskell's polymorphism).

Ideally I should give opcodes concrete monomorphic types and probably recover Csound's limited polymorphism by duplicating opcodes for different types.

ochre

Copperbox revision 2775.

I've switched to the monadic phantom layer, removing the tagless phantom code. Also I've started adding "prim-ops" for the Csound built-in opcodes and functions.

ochre

Copperbox revision 2774.

I've re-implemented the tagless phantom typed layer with a state monad instead. The types are much simpler, so I've included the all important Num and Fractional instances for signals.

The new monadic layer is in a style I've never used before - previously I've had code generators that could collect statements using a monoid so the user code would use the do-notation with a Writer as the underlying monad. Here the monad builds a single expression (usually nested) - the expression has no mempty or mappend so it is built with a library of combinators that model the syntax faithfully, user code does not use the do-notation.

ochre

Copperbox revision 2773.

I've added a tagless, phantom typed layer, but it is too complicated - I'll have to rethink and possibly use a monad instead.

ochre

Copperbox revision 2772.

I've renamed the cast constructors and made the ref type monomorphic - Ochre can now only have KSig and ASig refs (possibly global).

ochre

Copperbox revision 2771.

I think I've designed a type system for Ochre. I struggled with this before ("my first type system") but really it is the same as designing a typed library, plus cribbing some type signatures from SML as I have effects (ref cells and output) within the language rather than stratified as monadic effects.

Revision 2770 forgot to add the new file Typing.hs which is the mock-up of type system in use.

swidgets

Copperbox revision 2769.

I've added metronome style tempo setting to the SWDisplayWords widget.

Tempo is important for this widget as it is supposed to animate counting patterns like "one-e-and-ah, two-e-and-ah".

swidgets

Copperbox revision 2768.

Surprising development - first Java commit to Copperbox... (swidgets = Stephen's widgets)

I've started developing the Processing GUI widgets a bit more seriously. It turns out that advanced "Processing" is actually Java - Processing (the environment / compiler, whatever...) has no concept of shared libraries written in Processing (the language) so you have to write libraries in Java. This isn't a huge difference - Processing (the language) seems to be Java less some bits and with other bits implicit to save typing.

lirio

Copperbox revision 2767.

I've implemented an example that generates a full score (only two bars). The result is printable LilyPond.

lirio

Copperbox revision 2766.

More work on score pretty printers. Score now exports equivalents of the wl-pprint combinators (in monadic guise), ScoreDoc builds LilyPond syntax with them.

lirio

Copperbox revision 2765.

Initial work on percussion, plus extending note lists with beam grouping.

lirio

Copperbox revision 2764.

Implemented relative note and rest functions, so now there is some output at least.

lirio

Copperbox revision 2763.

Lirio is a LilyPond pretty printer / formatter to replace Neume and New-Neume.

Lirio is a clean rewrite / simplification of New-Neume. The current code is a Sunday hack which I wanted to do to work out some design issues, but as I am contracting at the moment I don't know when I'll have time to work on it further.

Vis my last post, I've been experimenting with Max MSP. I haven't bought it yet as the demo lasts for a month and I've had some issues with my MacBook. I expect I will buy it at the end of the month, and if I do I'll primarily be using Max MSP rather than Haskell over the summer.

wumpus-lite and "wumpus hiatus"

Copperbox revision 2762.

Added an experiment - Wumpus-Lite.

Wumpus-Lite is an idea towards reimplementing Wumpus so it can generate size efficient PostScript. Currently Wumpus takes no advantage of PostScript's ability to create procedures so the output files are huge. Wumpus-Lite is my initial thought towards embedding procedures in the EDSL.

That said, Wumpus-Lite is just a code dump. I'm not going to actively work on it in the near future, and Wumpus itself is also on indefinite hiatus (just like Stereolab!).

In fact, I'm about to change my working method entirely so the recent work like the Processing OSC experiments won't see any further work either. The new work should still go into Copperbox and it will still be open source, but it will be quite different. It won't even be in Haskell - this is for pragmatic reasons as the language I'm switching to is tailored to music and, importantly, has a large, active community of people using it to make music.

There may be a gap of a few weeks before I have any of the new work is ready to commit as I will be learning a new language...

processing / chuck

Copperbox revision 2761.

More fun with multimedia - toggle drum GUI in Processing that triggers samples with Chuck.

Processing GUIs for OSC

Copperbox revision 2760.

I've started a new "project" making GUIs with Processing to control OSC instruments.

I'm not sure if eventually I'll try to generate them with Haskell or whether it will be best simply to work always in Processing, but working in Processing does seem a bit more fun and flexible than using Pd.

ochre

Copperbox revisions 2758 and 2759.

Updates to the directory structure.

The compiler modules are now in their own sub-directory Compiler. This is to avoid clutter as more modules like Phantom are added to make the embedded language more convenient but aren't part of compilation.

ochre

Copperbox revision 2757.

More work on built-ins.

Csound's built-in functions like abs and the trig functions have quite a nice implementation - as they are monomorphic we can overload them in Haskell and still generate good types in the embedded language. Unfortunately opcodes don't work as well - we need a class per opcode if we want overloading. At the moment we use subscripts on the opcode name instead - an opcode ends in A if it generates an A-rate signal, K if it generates a K-rate signal.

ochre

Copperbox revision 2756.

I've started work on a phantom typed layer and implementing a library of the built-in opcodes. Ochre needs these to be usable...

wumpus

Copperbox revision 2755.

Updates to examples in Wumpus-Drawing and new releases of Wumpus-Drawing and Wumpus-Tree for Hackage.

wumpus-drawing-0.9.0
wumpus-tree-0.20.0

wumpus

Copperbox revision 2754.

Updated wumpus-drawing to work with GHC 7.4 and the updates to wumpus-basic.

wumpus-basic-0.24.0 - new release for Hackage.

copperbox

Copperbox revision 2753.

Whoops - I had a couple of files missing from the Ochre project for quite a while, I've just added them.

wumpus-core-0.52.1 - new release of wumpus-core for Hackage to work with GHC 7.4.

wumpus-basic

Copperbox revision 2752.

Updated to work with GHC 7.4.

Mostly the changes are to type families, probably these would work better as functional dependencies but I don't want both in the same project. I suspect the changes mean Wumpus-Basic now only works with GHC 7.4.1 and above.

wumpus-core

Copperbox revision 2751.

Updates to work with GHC 7.4.

Renamed the internal format combinator (<>) to (><), this avoids name clashes with the new monoid alias.

ochre

Copperbox revision 2750.

I've implemented expression pretty printers for Csound. Previously I was reusing the Haskell expression printers, but Haskell and Csound sometimes have different symbols for operators so this needed fixing.

ochre

Copperbox revision 2749.

I've implemented a full translation from K Normal Form to Csound. Likely as not there will be some errors in the translation but I believe I've covered all the syntax that can be translated.
It's possible to write nonsense that is syntactically legitimate but cannot generate an instrument - but this should be caught be the translation. If I had type checking, some bad instruments definitions could potentially be caught earlier.

zmidi-core

Copperbox revision 2748.

I've reintroduced the changes that I made between after 0.2.0 but took out to make a minor update 0.2.1.

There is a new release for Hackage zmidi-core-0.3.0 that contains all the updates.

zmidi-core

Copperbox revision 2746.

I've reverted the code back to version 0.2.0 and amended changes to accommodate the Num superclass changes in GHC 7.4.

I'll upload a new version 0.2.1 to Hackage then add back the changes that were at version 0.3.0.


Copperbox revision 2747.

Added new archive for Hackage - zmidi-core-0.2.1.

ochre

Copperbox revision 2745.

I've added casts to the expression types (both top syntax and K Normal Form) so we can convert I time constants to K or A rate signals.

With the addition of casts I think I've worked out Ochre's type system, though I haven't implemented it to prove this belief. As Ochre is embedded in Haskell I probably can use GHC to get type correct code. It might be worth writing a standalone type checker to validate that I have worked out the type system.

ochre

Copperbox revision 2744.

I've added declaration site (Global or Local) to VarId. With this information we know whether or not to generate variable names with a g- prefix.

ochre

Copperbox revision 2743.

I've added tuple elimination in the style of Scheme's let-values - tuples can't be created they can only be eliminated from opcode calls that return multiple values. I've also added unary operators.

This gets the syntax to match the previous implementation of Ochre, what's left are the big pieces - the type system and syntax for codegen with the respective translation form K Normal Form. 

ochre

Copperbox revision 2742.

I've added ref cells to Ochre. This will allow two useful functionalities:

1. Accessing global variables - needed for multi instrument control.
2. Preventing variables being optimized away (coalesced) - needed for delay lines.

Of course at the moment Ochre has nothing like register allocation so there is no current danger of variables being coalesced, but this is a compilation step it should do.

ochre

Copperbox revision 2741.

I've eliminated booleans and relational expressions from the K Normal Form syntax.

Booleans are cast to ints - with a corresponding change to the type annotation of variables in let- bindings. Relational expressions are translated to if-the-else expressions where then produces 1 and else produces 0.

ochre

Copperbox revision 2740.

I've added RelOps and if-then-else to the Expression syntax (both top level and K Normal form), though they still need accommodating in the Csound code generator. The Csound code generator now needs a rethink...

ochre

Copperbox revision 2739.

I've restarted ochre taking the code from micro-ochre. micro-ochre will stay small as there is still a lot of work outstanding, include designing a type system.

So far, Ochre adds binary operators to the Expression data types.

micro-ochre

Copperbox revisions 2737 & 2738.

I've changed the rewrite passes to use explicit environments rather than use a combined monad wrapping the Fresh monad with a Reader. Using Reader wasn't simplifying the code enough.

(Not committed...) I went down something of a rabbit hole adding Lam and App to the top-level syntax. The idea was to allow modularization in the instruments that would be compiled out with inline expansion (Csound has nothing to readily compile user-specified procedures into). However the implementation wasn't very good - new rewrite rules could throw errors if the syntax wasn't right and I wasn't sure if I'd accounted for all the possibly valid translations. As the language will be embedded in Haskell I think I can just use Haskell (the meta-language) for abstraction.

If I'm successful with micro-ochre, I have plans for a version of Wumpus with user-level procedural abstraction to tackle the current code explosion in the generated PostScript. In this case I don't think I will want inline expansion either as I want the smallest code possible.

micro-ochre

Copperbox revision 2736.

micro-ochre a genuine EDSL compiler - it optimizes! - that works!

micro-ochre generates Csound instruments. Just two opcodes - oscil and out - are supported, but the compiler uses a "proper" intermediate representation (K Normal Form) and it does genuine optimizations (const folding, beta-reduction, useless let elimination). The final codegen is flaky but it generates the test instrument and that instrument works.

Depending how you count I first started working on this 10 years ago (generating RTCmix with PLT Scheme), so although the success comes with heavy caveats, I'm pleased.

Cont ML

Copperbox revision 2735.

I've now implemented the tail CPS transformation.

I think there might be a mistake in the paper "Compiling with Continuations, Continued" - the CPS transformation in Figure 8 uses syntax for lambda abstraction which is present in the untyped CPS syntax but not in the typed syntax in Figure 7. I've added Abs to the Val type in my implementation.

Cont ML

Copperbox revision 2724.

Initial work on an implementation of the Mini ML in Andrew Kennedy's "Compling with Continuations, Continued" paper.

Although I'm working on the larger typed language, I might avoid typing. I've written the parser and pretty printer, I haven't tackled the CPS transform yet.

copperbox updates

Updates to Copperbox...

Revision 2730 - added zformat, formatting combinators with an interface like pretty print combinators but no prettiness i.e. no fitting / line breaking.

Revision 2731 - added directory-script. This should replace directory-diff, however I'm not sure if I have a use-case to work on this project any more, so it might get punted to the long grass as it currently stands.

Revisions 2732 & 2733 - renaming hpj-pretty-expr to pretty-expr-hpj and reorganizing the source directories.

I've done quite a bit of work over the last fortnight, but I haven't felt like committing it until today. I had a processor meltdown this morning (the fan on the processor needs the contact "glue" re-applying) so I thought I better finally make a commit.

HMinCaml

Copperbox revision 2729.

Initial work on closure conversion.

directory-diff

Copperbox revision 2728.

I've changed the report to print the previous names of moved files and directories.

directory-diff

Copperbox revision 2727.

I've added a two continuation, two input stream parser. This lets me (fairly) easily encode rules to check wither an old path matches a new one - modulo inserts or deletes to one of the paths. Probably I should have implemented this with a finite state automata (making it closer to lexing than parsing), but I know how to easily implement parsers.

Testing that an old directory has the same path as the new one, with a directory "Current" removed somewhere along the path is:

    test = prefix >> symbolL "Current" >> suffix

Note - no doubt I will change the combinator names.

HMinCaml

Copperbox revision 2726.

I've implemented constant folding and useless let elimination.

I've encoded these two with a direct environment (no Reader monad) and pattern guards. This seems like a big improvement - once I've implemented closure conversion, I'll change the previous passes to use direct environment passing pattern guards.

directory-diff

Copperbox revision 2725.

I've added some specific checks for the project I'm working on. Maybe at some point these should be generalized to encode arbitrary checkers for file system "patterns".

directory-diff

Copperbox revision 2724.

I've added timestamps to the report output for the toplevel directories. Plus I've moved Main to the top of the src folder. Seemingly GHC / Cabal doesn't recognize Main as Main if it is not at the root of the directory tree.

HMinCaml

Copperbox revision 2723.

I've added some optimization passes - alpha renaming, beta conversion and inline expansion. I've also renovated the HMonad so it is only run once, the monads built on top of it are run as local effects (which was a design pattern in one of Strafunski papers).

directory-diff

Copperbox revision 2722.

Reworking of directory-metrics to diff two dir listings. Output from the Windows / DOS dir command is too noisy to diff, so this utility does a "semantic" comparison.

Note - it has some hard-coded special behaviour for my use-case - i.e. it recognizes a certain pattern of delete and new as a move. It doesn't investigate files to look for "genuine" moves as it works off-line on dir listings.

ochre

Copperbox revision 2721.

New project - ochre.

This is a reworking of orchsyn with a simpler expression type - as Csound supports if-then-else I think I can avoid lambdas in the expression language, this makes Ochre quite a bit simpler than Orchsyn.

I've implemented the same expression language optimizations as Orchsyn, which means I'm up to converting the expression language into Csound, the big step...

directory-metrics

Copperbox revision 2720.

Initial work on pretty printing / metrics reporting.

directory-metrics

Copperbox revision 2719.

Fixed a severe bug in tree building that was generating wrongly-shaped trees.

Added first sets of metrics.

directory-metrics

Copperbox revision 2718.

I've implemented tree building, so now directories are represented recursively. The code isn't efficient as it doesn't account for the fact that Windows directory listings are usefully ordered (erm, preorder? I can never remember without making a drawing on paper).

directory-metrics

Copperbox revision 2717.

Work towards tree building (and forest building). As I think I have a forest rather than a tree I think I can build the forest lazily. At the moment I'm struggling to build even a tree though...

directory-metrics

Copperbox revision 2716.

New (small) project to extract directory metrics.

It is intended that metrics are derived from listings made at the command line, rather than run directly on the file system. To this end I've written a parser for Windows dir listings. The parser uses a new implementation of parser combinators that should stream and thus can be used for very large files.

HMinCaml

Copperbox revision 2715.

I've restarted work on HMinCaml - actually I restarted work last week but this is the first time it feels like it merits a commit.

I've decided to work in regular Haskell rather than UUAG. So far I have up to k-normalization "working" - some of the code is of pretty dubious quality hence the scare quotes. Type annotation works for simple types though fails for the example Ackerman function. Hopefully I can find a satisfactory reference for type directed translation, I'm a bit out of my depth at the moment.

I don't intend generating SPARC code as I have no SPARC machine to run it on, I'll stop at MinCaml's idealized assembler. My interest is really to get up to closure conversion, anyway.

glsl-syntax - abandoned

Copperbox revision 2714.

I've partially updated the syntax to make better distinction between declarations and declarators, but I've decided to abandon the project again. Basically I never had a concrete use for a GLSL parser and I was using the project to learn something about the GLSL language. However, the C style syntax for declarations is so horrible that writing a parser is no fun and hardly instructive. My time is better spent on other things.

glsl-syntax

Copperbox revision 2713.

The parser now works - it must never have been working when I abandoned it as I had to relax the distinction in the parser grammar between identifiers and field selectors - basically the lexer never knows what is a field selector so it has to class everything as an identifier.

The parser isn't going to be robust - I think GLSL code in the wild uses CPP which it obviously can't handle. Also I think the grammar for GLSL has changed vis void main () and void main (void) - as my parser is LALR, which is always a struggle to use, I'm not going to rush to make it handle errors and discrepancies.

glsl-syntax

Copperbox revision 2712.

I've picked up on the old GL Shading Language parser and pretty printer. It will be useful to change the pretty printer to use hpj-pretty-expr as the GL Shading Language is big enough to be considered industrial strength.

Clearly I hadn't discovered Hughes lists when I first worked on GLSL as I was using Data.Seq in the syntax tree so I could build with snoc-ing.

There is some connection between shading languages and Csound and Supercollider instrument languages. Both types of language essentially describe what goes on in a single iteration of a rendering loop.

hpj-pretty-expr

Copperbox revision 2711.

I've changed languages to only use one module - this should make for a better user API. I've worked up the Ocaml printers, the other languages need work.

hpj-pretty-expr

Copperbox revision 2710.

I've started a new project for pretty printing expressions.

The base code is from Norman Ramsey's paper "Unparsing Expressions With Prefix and Postfix Operators". My hypothesis is that if I define sets of expression / operator printers for languages like C or Haskell people can use the library and get good parenthesized pretty printing with only a little more code than writing a naive (brackets everywhere) pretty printer.

orchsyn

Copperbox revision 2709.

I've got a bit stuck with Orchsyn due to building code within a monad. The do-notation seems to make the embedded language a statement language, but this means I don't know what types the opcode built-ins should be (so they can account for arity of the result).

As an alternative, I've be experimenting using the tagless-final style to embed an expression language with sharing within normal Haskell (not the do-notation). I'm quite pleased with the results - I've embedded ref cells, lambda and apply, sharing let, if-the-else and primitive apply (for calling built-ins). The only problem is an expression language will need a real compiler - the abstract syntax is too far from Csound's imperative language to just pretty print to Csound.

This commit stores a series of expression languages (adding more features) as I don't want to lose them.

orchsyn

Copperbox revision 2708.

I've added an environment for binding pfields to names at init time. User code can now reference declared pfields without the risk of declaring them twice (orchsyn doesn't have a proper notion of scoping).

orchsyn

Copperbox revision 2707.

I've added lvalues to the monadic builder to make it support reassignment. The syntax is not very pleasant as I need to cast lvalues to rvalues on the righthand side. Also I've got rid of some overloading - now there are separate functions to demand variables of different types (rates - I K A).

orchsyn

Copperbox revision 2706.

I've worked up the Instr monad and added a fairly large set of Csound builtins. Orchsyn is now comparable to ZSnd the previous prototype.

There is still a lot to do with Orchsyn, as I haven't implemented anything of the compiler (which should optimize variable use) or worked out how to build instruments compositionally.

functional envelopes

Whilst writing FMSS, I didn't spot that envelopes can be a function from Duration to Signal.

Idiomatic Csound envelopes are defined contingent to note duration - pfield 3:

idur = p3
; pass envelope sweep from 0.0 to 600
linseg 0.01, idur, 600.0

In FMSS, rather than have the note duration as a free variable (which might have lead me to the functional formulation sooner...) I had global reference idur. Maybe the functional view, if it can build other signals, makes it possible for UGen assemblies to be be more compositional.

majalan

I haven't thought enough about "procedural scores" so far - procedural being a score that is somehow run rather than specified as a note list.

The most obvious first procedural score is a click track, here is a Csound instrument for clicks:

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

; Set the 0dbfs to 1.
0dbfs = 1

;
; A click for click tracks.
;


instr 1
  idur      = p3
  iamp      = p4
  ihdur     = idur * 0.5

  kampenv   expseg 0.01, 0.005, 1.0, ihdur, 0.02, ihdur - 0.005, 0.01
  kbeta     line 0, p3, 1

  ; pass envelope sweep
  kpenv  linseg 0.01, p3, 600.0

  a1        noise     1, kbeta
  abw       butterhp  a1, kpenv
            out       iamp * abw * kampenv
       

endin

majalan and zmidi-basic

Copperbox revision 2705.

Various updates to Majalan and ZMidi-Basic as I make Majalan more like ZMidi.

I'm a bit at a loss for ideas on high level structures - how to make systems out of events and how to manipulate them, so work has been slower than I hoped.

majalan

Copperbox revision 2704.

I've ported the EventList with efficient concatenation from ZMidi-Basic. This will form the basis of Majalan-Basic, which is pending a rewrite.

majalan-core

Copperbox revision 2703.

I've tidied up after yesterday's work deleting old modules and renaming others. The work should now be good enough for me to port the score language from ZMidi-Basic to Majalan (Csound).

majalan-core

Copperbox revision 2702.

I've hacked Majalan-Core so it works with the new NoteList. This really is a hack - although the code seems to work, much of the odd code has been left it and will need removing.

orchsyn

Copperbox revision 2701.

I've added the phantom typing for control and audio rates as originally done in ZSnd. This code had some problems so it will likely need reworking once I get enough code in place to actually run Orchsyn.

orchsyn

Copperbox revision 2700.

I've added a module defining the builtin Csound functions.

orchsyn

Copperbox revision 2699.

New project - orchsyn - orchestra synthesizer.

This replaces FMSS, I've decided there is a case for an EDSL to generate Csound orchestras.

Previously my feeling was that generating Csound instruments was unwise - with ZSnd, the earliest prototype, descriptions were always longer than the Csound they generated and the mechanisms of the generator lost too much of power and generality of Csound (it wasn't a full embedding). ZSnd had no real benefits to counter these problems.

Still, Csound orchestras have severe modularity problems - basically there is no modularity. Instruments cannot be put in libraries to be imported by an orchestra, they have to be copy-pasted and tweaked not to name clash. An embedding can inherit the modularity features of the host language, so even if the instrument descriptions are more verbose than the corresponding Csound there is the possibility that this can be countered by introducing modularity and allowing the definition of libraries of instruments.

majalan-core

Copperbox revision 2698.

I've changed the argument type from Double to a union of Int or Double. This allows neater printing.

majalan-core

Copperbox revision 2697.

I've added a dictionary of column specs so multiple instruments can be printed in a score. Also the initial test appears to work...

majalan-core

Copperbox revision 2696.

I've implemented (but not tested) event list printing with both formatted column widths and carry printing i.e. using a single dot as an ellipses when subsequent values are the same.

majalan-core

Copperbox revision 2695.

I'm reactivating Majalan so it can follow the re-designed note list / score in ZMidi-Basic.

Unfortunately, Majalan-Core is really crufty due to a bad initial design where I didn't know what I was doing. So I'll have to redesign that first, before I can rework Majalan-Basic. 

zmidi-basic

Copperbox revision 2694.

I've now reworked the core data types to have nice concatenation (rather than inefficient concatenation).

zmidi-basic

Copperbox revision 2693.

I've implemented stretch and reverse for the new event list.

Tomorrow when I've more time, I'll integrate the new list into the code - adding it invalidates a lot of the previous code so it will take a while to do.

zmidi-basic

Copperbox revision 2692.

Work on a better EventList data structure that supports cheap concat. The new structure supports cheap concat as it is represented by a binary tree of lists, I've still to work out how to do transformations which will probably flatten any trees that have built up in the structure.

supercollider

Copperbox revision 2691.

I've fixed the problem with the hi-drum, it seems like it was another problem with mis-using conditionals in server / synthdef code. It doesn't seem like I can use a symbol (or boolean) to represent whether to select the hi-drum, instead I have to follow the Csound code and represent low drum with 0.0 and hi-drum with not 0.0. My current understanding is that all values on the server must be floats...

supercollider

Copperbox revision 2690.

Improvements to the FM drum instrument. The low version now sounds equivalent to the Csound version, the hi version is still not quite right.

To get the equivalent of Csound's rand noise signal I used WhiteNoise and for transeg like envelopes setting the curve of an Env to a list of curve shapes works. Using the spectrum view provided by Audacity has proved essential for comparing Csound and SuperCollider instruments. It was crucial last summer for comparing CLM and Csound instruments likewise.

supercollider

Copperbox revision 2689.

I've added a SuperCollider translation of the CLM tubular bell instrument that I converted to Csound last summer.

supercollider

Copperbox revision 2688.

I've added yestersday's fm-gong and fm-drum to copperbox. Both are ports of instruments in the CLM-4 distribution. Fm-drum still needs some work as it doesn't sound like my Csound version.

supercollider gong

Here's the FM gong I implemented last summer in Csound:

http://varioussmallfires.blogspot.com/2011/07/fm-gong.html

SynthDef("fm-gong", {
 arg freq, dr = 1.0, amp = 1.0;
 var mod1sig, mod1f = freq * 1.16;
 var mod2sig, mod2f = freq * 3.14;
 var mod3sig, mod3f = freq * 1.005;
 var idx1a = 0.01 * mod1f;
 var idx1b = 0.30 * mod1f;
 var idx1scaler   = idx1b - idx1a;

 var idx2a = 0.01 * mod2f;
 var idx2b = 0.38 * mod2f;
 var idx2scaler   = idx2b - idx2a;

 var idx3a = 0.01 * mod3f;
 var idx3b = 0.50 * mod3f;
 var idx3scaler   = idx3b - idx3a;

 var mod1env, mod2env, mod3env, ampenv;
 var carsig;

 mod1env = EnvGen.kr(
  Env(levels: [0,1,1,0], times: [0.75*dr, 0.24*dr, 0.01*dr]),
  doneAction: 2);

 mod2env = EnvGen.kr(
  Env(levels: [0,1,0], times: [0.02*dr, 0.98*dr]),
  doneAction: 2);

 mod3env = EnvGen.kr(
  Env(levels: [ 0, 0.3, 1, 0.5, 0], times: [0.15 * dr, 0.15 *dr, 0.45*dr, 0.25*dr]),
  doneAction: 2);

 // Exp curve...
 ampenv = EnvGen.kr(
  Env(levels: [ 0, 1, 0.001], times: [0.002, dr - 0.002], curve: \exp),
  doneAction: 2);

 mod1sig = SinOsc.ar(freq: mod1f);
 // envelope the signal, afterwards
 mod1sig = mod1sig * ((idx1a + idx1scaler) * mod1env);

 mod2sig = SinOsc.ar(freq: mod2f);
 // envelope the signal, afterwards
 mod2sig = mod2sig * ((idx2a + idx2scaler) * mod2env);

 mod3sig = SinOsc.ar(freq: mod3f);

 // envelope the signal, afterwards
 mod3sig = mod3sig * ((idx3a + idx3scaler) * mod3env);

 carsig = SinOsc.ar(freq + mod1sig + mod2sig + mod3sig);

 Out.ar(0, carsig * ampenv * amp); 

}).store

Possibly I can use 'mul' rather than envelope the modulator signals afterwards.

SuperCollider notes

Copperbox revision 2685.

Work on SuperCollider learning notes. I haven't worked out what I want to say yet - possibly I want to make notes for people who know functional programming well but are new to SuperCollider. I don't want to make a general introduction as there are two of these in the SuperCollider book.

As I don't know what I want to say and I'm learning as I go along, the notes are insubstantial (less than a page so far). I'd like to make a daily commit to Copperbox - I want to get back into this habit, but I might not bother with an attendant blog post as there isn't much to say about the work at the moment.

jerry-osc

Copperbox revision 2684.

I've added a Double64 constructor to the Atom datatype - SuperCollider needs this non-standard argument.

Note to self - I will have to make Jerry-OSC gracefully handle argument types it isn't hard coded to recognize. Currently it fails with a fatal parse error.

Also I've added a place holder TeX document so I can collect notes as I learn SuperCollider. I'm going to be busy this month, so I might not have time for much Haskell coding, but I should be able to fit in some dabbling with SuperCollider each day.

jerry-supercollider

Copperbox revision 2683.

Work on getting jerry to talk with SuperCollider rather then just send commands (and not listen).

Ahem, my knowledge of writing networking code is non-existent so I'm having to do everything from scratch.

jerry-supercollider

Copperbox revision 2682.

New (mini) project to talk to SuperCollider with jerry-osc.

Currently it has a single operation - shutdown the server...

zmidi-basic

Copperbox revision 2681.

I've removed the TimeSpan module as objects are now annotated with duration rather than TimeSpan.

zmidi-basic

Copperbox revision 2680.

I've improved the symbolic representation so reverse now works. Note, TimeSpan no longer makes sense as all TimeSpan's now start at zero, so caching duration would be better.

zmidi-basic

Copperbox revision 2679.

First attempt to add symbolic transformations to ZMIDI - e.g reverse, scale, move.

Currently the implementation doesn't work...

zmidi-basic

Copperbox revision 2678.

I've added Chains (as per Wumpus-Basic and TikZ) and fixed a bug with MIDI duration calculation.