Author |
Message |
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Mon May 31, 2010 2:34 pm Post subject:
Zylaphon C# work blog |
|
|
I'm going to use this thread as a C# work blog for Zylaphon. Technical and design comments/suggestions welcome.
Zylaphon sprang from earlier unfinished work in C++, and began with a translation of the C++ measure class into C#. The design of this earlier system had little concern for generality however and its methods and classes cross contaminated one another. It was only after translating the C++ measure into C# that I began think about redesigning the system, rather than simply translating it. Which brings me to the most recently completed unit of work which was the untangling of the Measure class and the ChannelBar classes.
The inheritance sequence from abstract toward concrete for ChannelBars is:
ChannelBar (virtual)
ChBarMetered (virtual)
ChBarDiatonic
The ChBarDiatonic models bars of music in staff form. Everything to do with formatting the time encoding elements of the bar are provided by ChBarMetered. The utility of this generalization is that, for example, adding a class for indefinite pitch elements becomes relatively trivial. Further it is my expectation that I will be able to easily implement a time ruler/book-mark class by inheriting from ChBarMetered. And a non-diatonic channel bar class, one suited to tunings not properly expressible or manipulable with diatonic notation, would at least start with that part of the problem solved.
This cleanup took two days to complete. Everything seems to be working, but problems can always turn up later and eat more time. My next task is to cleanup the implementation of header and footer data and its channel display formatting. _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Wed Oct 27, 2010 11:15 am Post subject:
|
|
|
Summer and most of fall the entire staff of Zylaphon was kidnapped and forced into slave labor refurbishing Zylaphon's head quarters. That out of the way, MeasureView class -- now renamed Channel Bar and Measure Tool -- has been essentially finished and the final push to fill in stubs and stomp out bugs before the first release of code January 1st 2011 is underway. _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Sat Oct 30, 2010 7:46 pm Post subject:
|
|
|
Hmmm. In truth I'd rather code than blog about codding. But lets force one out here:)
Generally I work on the difficult stuff during the day when I am not doing chores or out walking. In the evening I work on easy stuff like UI refinement. It is the implementation of Zylaphon's UI that's the mindlessly entertaining crank work -- I suppose it must be something like the pleasures some people get from Sudoku. But for me, programming is the only solitary mind game I've ever enjoyed--but I digress. Though the act of writing UIs my be pleasantly easy, the design of good UIs is challenging. One is usually best advised to follow “best practices and standards.” In the middle days of Windows, NT to .NET, the M$ IDEs were unconcerned about the fairly onerous price for innovation or even variation their libraries made one pay. I know nothing of the machinations of Redmond but I always felt that was partly a strategy to force uniformity for the sake of making computer interaction less confusing and threatening to first timers. Now that most of the world has some comfort with computers, this is no longer relevant. And certainly the tools of .NET 4.0 feel liberating compared to tools of yore. And so taken with this new found freedom I decided to try to design a UI where form follows function with a style of interaction that is pleasing or even a joy to use. I don't know if I can attain that level but it is certainly my goal, because I really do hope to live long enough to use the freak'n thing!
But the whip cracks and so it's back to the code mines I go--till midnight anyway. _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Tue Nov 09, 2010 7:02 pm Post subject:
|
|
|
Deadline induced triage time.
Most significantly the generation of Meter object instances will not have the hoped for generality on January 1st 2011. However, the Meter generators that exist are all those that are required for full generality because they are parametrized with start and end indicies.
public AccentLevel BuildSimpleMap(int numerator, NDenom denominator, int mapStartIdx, int mapEndIdx)
{
. . .
}
And are currently used to build simple asymmetrical meters. What is required is a fairly simpleminded recursive descent parser to automatically apply these generators as needed to build complex Meters. And simple though it may be, it still requires time.
BTW Below is a screen shot of a complex Meter, 10/4. It is at the at the last user input stage before map build, which is required before the division are filled. Used in score it will not parse note lengths properly because of want for the parser to properly parse the user Meter specification. Of course the user can create the “parts” of complex Meters and assemble them in the score to suit what ever needs -- but that is not really very nice.
Also, no MIDI and no Chords by 1/1/11 though I expect to have chords in progress at that time. The sequence of development that I envision is Chords, MIDI, and graph infrastructure. Of the three, graph infrastructure will require the most intensive coding and have the least immediately visible effect on the program.
But now it's back to the code mines to complete the code that adequately handles all instances of tuplet beaming.
Description: |
|
Filesize: |
65.2 KB |
Viewed: |
908 Time(s) |
This image has been reduced to fit the page. Click on it to enlarge. |
|
_________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Thu Nov 11, 2010 9:01 pm Post subject:
|
|
|
Continuing the topic of future work, the graph infrastructure mentioned above is the foundation of the data schemes that model the majority of musical abstractions, and certainly all the high level abstractions, that Zylaphon deals with. And though Zylaphon's first significant UI is little more than a gimpy notation program that is not its destination. The nature of Zylaphon is distinct from the nature of notation programs primarily because of its integration of graph resources. I'm guessing that it will take two years of work after first release 1/1/11 for these resources to be mature enough to be of interest to the end user. That's assuming I remain Zylaphon's lone coder over the next two years and that I don't surrender to the desire to get a good sequencer working before I finish getting graphs up-and-running and with at least some embedded heuristics in them. _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007 Posts: 2067 Location: Berks County, PA
Audio files: 89
|
Posted: Wed Nov 17, 2010 5:05 pm Post subject:
|
|
|
bachus wrote: | What is required is a fairly simpleminded recursive descent parser to automatically apply these generators as needed to build complex Meters. And simple though it may be, it still requires time. |
How are the parser generators for C#? Python has a couple of nice ones, and even for simple grammars, it is handier to capture and maintain them as grammars than as ad hoc code.
I don't like the Java parser generators as well -- they are perhaps more efficient for big languages being parsed, but harder to use. Lately I have been writing some Jython code, which is Python on top of Java Virtual Machine with automatic access to Java libraries. So, I could have my Python parser generator and Java if I want.
I believe IronPython builds atop C#. Might be worth a look some time when you need a distraction _________________ When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Wed Nov 17, 2010 6:51 pm Post subject:
|
|
|
Acoustic Interloper wrote: | How are the parser generators for C#? |
Thanks, a good suggestion, but to be honest I don't know. BISON (a YACC-alike) is the only parser generator I've ever used or even looked at, and it would be overkill here. When I say its needs are simple-minded I really do mean simple minded. I can imagine meters too complex for what I have in mind; but those kinds of meters are, in my analysis, better modeled as expressions of rhythms which Zylaphon will treat as a distinct Class with distinct semantics, data model, and method of definition (user input). _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Wed Nov 17, 2010 10:44 pm Post subject:
|
|
|
I think the paper and pencil phase of creating the parser will take between 15 minutes and an hour. I think coding could take two to four days. So why don't I just do it?
Well... I know my first laid plans are sometimes wretchedly ill conceived. And If my initial conceptualization of this problem is incorrect it might take ten days. This is more time than I can spend on it while having any chance of taking care of all the known bugs, stubs, etc, that are on my plate and which have a higher priority than the issue of complex Meters.
There is, of course, a quick and dirty fix lurking about. The minimum set of data for generating a meter could be read from a text file. But that is the first step down a road I do not want to travel. It simply seems wrong to require a user to create a lengthy tedious data file to accomplish a basic task. Truly I want the program to encourage experimentation by making it easy to do by providing tools that present the abstractions of music in a meaningful visual form that is easily grasped by musicians. And I want it to feel that way from the beginning.
As it is, I regret that the Mode Manager cannot provide a more suitable interface at first release. It is the bare functional minimum. It's mature form must wait till MIDI is running and I've written a ScoreChannelViewLabel Control Class. _________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Sun Dec 19, 2010 7:53 pm Post subject:
|
|
|
Back in the day I put in my time writing code for small DEC 11 series machines which typically allotted 64K of RAM per process/user – 32K for program 32K for memory. And so I now sing unabashedly the joys of RAM, lots and lots of RAM. And chant the rubric that “one should never compute that which can be stored”. As a conservative example find displayed below the data members of Zylaphon's Accent class.
Every meter one defines in Zylaphon posses an accent map which is an ordered array of Accent objects, one such object for every 256th note in the meter or 32 Accent objects per 8th note. And every event in a Zylaphon composition that has an intrinsic metric position possess an index into the accent map that is relevant to its context, i.e. the accent map of the Meter instance of the ChannelBar of which the event is a member.
Of the 13 Accent data members only three, m_duration, m_level and m_group provide data directly relevant to the metric quality of the events that occur on that Accent. The remaining 10 members provide information about, and embed the accent in, the context of its meter. This data clarifies , simplifies and expedites both computation and analysis. It is profligacy with a purpose.
Description: |
|
Filesize: |
83.19 KB |
Viewed: |
988 Time(s) |
This image has been reduced to fit the page. Click on it to enlarge. |
|
_________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Tue Dec 21, 2010 7:57 pm Post subject:
|
|
|
Does bread fall jelly side down? A few days after writing
Quote: | Deadline induced triage time.
Most significantly the generation of Meter object instances will not have the hoped for generality on January 1st 2011. However, the Meter generators that exist are all those that are required for full generality because they are parametrized with start and end indicies. |
I discovered that even such elementary meters as 5/4 would have problems without the full generalization scheme. So rather than expose Zylaphon to public scrutiny with such meager coverage I bit the bullet and had at it. The meter map parser turned out to be trivial, and was implemented as a single pass incremental compiler, where the beats of each increment are all divisible by either two or three. The auto metric parsing algorithms which I thought would be trivial to generalize ended up in a complete rewrite which only today came to a reasonable stopping “place”. (“place” your favorite curse words here)
Below is a bar of 10/8 grouped as 2/4 + 6/8. The second staff of the bar (the second channel bar) had the form of the one above it before the first note was transformed into a whole-note. Note that there is no whole note in second staff, rather there is a series of tied notes that sum to a whole. And the notes and ties reflect the metric grouping of the meter (2/4+6/8 ). Had the same operation been performed in a notation program the second staff would show a whole-note followed by a quarter-note. Because Zylaphon is a composition program, not a notation program, the graphic transforms stress the underlying musical semantic content of each element displayed. As stated elsewhere Zylaphon models meter as the basis for low level temporal expectation. Zylaphon's representation of the duration of a whole-note in the context of 10/8(2/4+6/8 ) brings into focus (for both human and machine) how the rhythm of the line either meets, or in this case, violates metric expectation. Clearly in this representation the distinction is qualitative not quantitative as the latter would require an analysis of what had come before.
BTW the second staff was highlighted by double clicking on it. This activated the “Channel and Measure Tool” a portion of which is seen on the left. Clicking on the microscope button opened the ZyDebug info window on the right. These microscope buttons, wherever they occur, open data views of use to developers. ZyDebug – isn't that a kind of Cajun music?
Description: |
|
Filesize: |
172.79 KB |
Viewed: |
1026 Time(s) |
This image has been reduced to fit the page. Click on it to enlarge. |
|
_________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Wed Jan 12, 2011 7:33 pm Post subject:
|
|
|
While making the video demo of the ChannelAndMeterTool I discovered a bug in the formatter and had to spend half a day tracking it down which revealed two things. First I had not carried the generalization as far as I had planned as its the first stage. Second, was that the learning curve for someone who had no prior contact with Zylaphon would be nasty steep. And anyone who wanted to add a new Channel type would have to deal with formatting and editing. So I decided to do the rework and thorough documentation at the same time--which is where I will be for a while. And speaking of formatting and adding new Channel types, below is a drawing of how I imagine some aspects of Micro-sounds might work in Zylaphon. If one held one of the frequencies fixed then one could either manipulate beats or the frequency. Of course there would have to be a “back-end” doing the actual computation. I'm not suggesting that this is particularly desirable, only harping on the theme of Zylaphon's felicity toward extension.
_________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
|
Back to top
|
|
|
dalekay
Joined: Nov 16, 2003 Posts: 145 Location: Lancaster CA
|
Posted: Mon Feb 07, 2011 12:24 pm Post subject:
|
|
|
sounds and looks like a cool project ...
I'll try to poke into this thread over time ...
Looking forward to see it work midi wise for sure ... I would like very much to be able to assign midi, sysex to items to feed the synths for sure.
Dale _________________ dale
many links, cd baby or origo planet to find what we have for sale, myspace, facebook or reverbnation to name a few to hear what we are up to current ... |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
Posted: Sat Jun 15, 2013 10:26 am Post subject:
|
|
|
A tempo channel bar class and its progenitor classes, ChBarChronon and ChBarValuePlot have been implemented though some work remains to be done.
ChannelBar → ChBarChronon → ChBarValuePlot → ChBarTempo
Clicking an element in a ChBarValuePlot collapses all measure interstices on a page to provide a continuous plot. When staff justification code is completed bar lines will remain in place and glyph spacing will expand to fill each measure. Whether spacing is consistent across bars depends on the score formatting method chosen.
Description: |
|
Filesize: |
69.47 KB |
Viewed: |
33025 Time(s) |
|
Description: |
|
Filesize: |
61.41 KB |
Viewed: |
33026 Time(s) |
|
_________________ The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004 Posts: 2922 Location: Up in that tree over there.
Audio files: 5
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007 Posts: 2067 Location: Berks County, PA
Audio files: 89
|
Posted: Sat Jun 15, 2013 11:43 am Post subject:
|
|
|
Thanks for the update. It looks nice _________________ When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
Back to top
|
|
|
dalekay
Joined: Nov 16, 2003 Posts: 145 Location: Lancaster CA
|
Posted: Tue Oct 29, 2013 5:31 pm Post subject:
|
|
|
dalekay wrote: | sounds and looks like a cool project ...
I'll try to poke into this thread over time ...
Looking forward to see it work midi wise for sure ... I would like very much to be able to assign midi, sysex to items to feed the synths for sure.
Dale |
well ... a few years later and ... ?
like a good wine, it requires time ... be back in a few ... _________________ dale
many links, cd baby or origo planet to find what we have for sale, myspace, facebook or reverbnation to name a few to hear what we are up to current ... |
|
Back to top
|
|
|
|