Fernseher - User contributions [en]

Theoretical Pipe Variations

2009-03-30T23:02:53Z

129.42.161.36: New page: A set of characteristics of pipe spectra, useful in categorizing actual pipe sounds as well as synthesizing them. ===Frequency Variations=== *Typical large organ range is from 32' to 2' s...

A set of characteristics of pipe spectra, useful in categorizing actual pipe sounds as well as synthesizing them.

===Frequency Variations===
*Typical large organ range is from 32' to 2' stops, which puts us around C0 up through C9, or 9 octaves and a note. This is 109 notes. (N)
*For a given note, there are several possible mutation frequencies that pipes could have that would not fall on perfect equal temperament notes: (M)
**Harmonic 1: Unison (that is, no mutation) (N+0.00)
**Harmonic 3: Twelfth (N+19.02)
**Harmonic 5: Seventeenth (N+27.86)
**Harmonic 6: Nineteenth (N+31.02)
**Harmonic 7: Twentieth (N+33.69)
**Harmonic 9: Twenty-third (N+38.04)
*For each mutation of each note, we could be slightly detuned below, perfect, or slightly detuned above, yielding 3 tunings. This will allow things like Voix Celeste, etc. In reality, the detuned mutations would only be used for certain ranks, against certain standard string-like ranks. Most Mixtures would never be detuned, etc. But, the variations could exist. The detuned pipes will probably just be by a couple of cents from the mutated frequency. (D)

These combinations yield 1962 fundamental frequencies that we have to generate pipes for, possibly a handful more for multiple octave mutations that wouldn't normally fall in the C0-C9 range (meaning we'd need unmutated notes up to C12, which at 67kHz is well outside human hearing...)

===Spectrum Characteristics===
*A given pipe can be open (all harmonics present), stopped perfectly (no even harmonics), or stopped imperfectly (even harmonics severely diminished, say at 1/4 of what it would be if open) (U, Sp, Si)
*A given pipe can be normally blown (all harmonics present), perfectly overblown (fundamental completely missing), or imperfectly overblown (fundamental diminished, say at 1/4 of what it would be if normally blown) (B, Op, Oi)
*A given pipe can be coherent, or have rotating phase shifts (each harmonics is 90 degrees out of phase with previous and next harmonic in the series, so 0, 90, 180, 270, 0..., like a triangle wave) (C, A)
*A given pipe can have harmonic decay in one of multiple modes, where the relative strength of the kth harmonics is k^(-d), where d is one of (Xd):
**00, or 0: uniform all the way to the cutoff frequency... not very realistic...
**05, or 1/2: subharmonic, slower than a perfect harmonic series
**10, or 1: harmonic, a perfect harmonic series. Sawtooth and square waves fall here.
**15, or 3/2: subsuperharmonic, slightly faster than a perfect harmonic series
**20, or 2: superharmonic, faster than a perfect harmonic series. Like a triangle wave.

===Bandwidth Limitations===
The spectrum for a pipe can be bandwidth limited as well. All synthesized waveforms for sound should be limited to 22050Hz at a maximum. Cutoff harmonics worth trying are:
*Pure (n=0, perfect). No real transition zone here. Fundamental only, everything else is nonexistant. L0p is just notational convenience.
*n=3. Normal strength fundamental, then diminishing begins.
*n=5
*n=13
*n=37
*None (n=0, imperfect). No cutoff here, all harmonics are full strength, up to the 22050Hz cutoff that everything has. L0i is just notational conveneience.

A bandwidth limitation can be perfect or imperfect (Lnp, Lni). A perfect limitation has a three harmonic transition zone, where the strength of the harmonic before the cutoff is 85% what it would have been, unlimited, the strength of the harmonic at the cutoff is 50%, and the strength of the harmonic after the cutoff is 15%. All harmonics below these are at 100%, and all harmonics above these are at 0%. An imperfect limitation also has a three harmonic transition zone, where strength well before cutoff is 100%, right before cutoff is 81.25%, at cutoff is 62.5%, right after cutoff is 43.75%, and everything above that is at 25%.

===Conclusions===
Given all that, we have:
*N+M+D determine fundamental frequency, of which there appear to be just under 2000 reasonable ones.
*Xd + U/Sp/Si + B/Op/Oi + C/A determine pipe family, of which there appear to be about 90.
*Lnp/Lni determine pipe color, of which there are 10.

90*10 yeilds 900 rank classes.
If each fundamental frequency is represented in each rank class, we would have about 1.8 million different theoretical pipes.

For convenience sake, these theoretical ranks will be named as follows:
XddxxyyzLnq_Mht

*Xdd is one of the decay modes, X00, X05, X10, X15, or X20.
*xx is U, Sp, or Si to indicate any stoppage
*yy is B, Op, or Oi to indicate any overblowing
*z is C or A to indicate phasing
*Lnq indicates color, where n is the cutoff indicator, or 0, and q is either p or i to indicate perfect or imperfect limitation
*Mht indicates that the rank is of mutation harmonic h (1, 3, 5, 6, 7, 9 (possibly 2, 4, or 8 for high notes)), and t indicates either u for under, p for perfect, or o for over to refer to any detuning.

Each pipe file or dft will have the actual fundamental frequency in cents included in the name after another underscore. This will take into account the mutation or detuning. Its the actual frequency of harmonic gap in the spectrum.

So, an example might be:
X10SiOiAL37i_M1p.rank

This indicates a harmonically decaying, imperfectly stopped, imperfectly overblown rank of pipes with alternating phasing, being imperfectly limited above the 37th harmonic, perfectly tuned at unison.

We will likely have 16,200 basic ranks of pipes. Each pipe of mixtures would count as a different rank here.

MIDI and the organ project

2009-03-30T21:53:12Z

129.42.161.36:

*[http://sessrumnir.net/organs/trunk/ SVN trunk for organ code]
*[http://www.die-orgelseite.de/pfeifenarten_e.htm Interesting site for pipe shapes and sounds]

*[[Pipe creation workflow]]
*[[Theoretical Pipe Variations]]

====MIDI and the organ====
MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.

The basics, as I think we will be using them:

Packet basics (we'll only be using 3 byte packet forms):

1 <3: opcode> <4: channel> 0 <7: arg1> 0 <7: arg2>

Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).

opcodes of relevance:
*0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.
*0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.
*0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)

For channels, we will use:
*0x0: Great (Solo) Manual
*0x1: Swell (Accompaniment) Manual
*0x2: Choir (below Great) Manual, if present
*0x3: Solo (above Swell) Manual, if present
*0x4: Echo (above Solo) Manual, if present
*0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.
*0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.
*0x7: Main Pedalboard
*0x8: Great stops only
*0x9: Swell stops only
*0xA: Choir stops only
*0xB: Solo stops only
*0xC: Echo stops only
*0xD: Third Pedalboard stops only
*0xE: Second Pedalboard stops only
*0xF: Main Pedalboard stops only

Our initial organ will only use channels 0x0-0x1, 0x6-0x7.

Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It'd be kinda a lot harder to make work right, I think.

We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi's numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.

Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don't even need to populate the board positions for the other channel boards.

Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don't need a pin for ground or power, I don't think... Though if there is room, I guess we could send it along there, too. Can't hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.

Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.

===Simple algorithm for key change detection===
After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor'ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don't have to analyze it, it hasn't changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.

Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.

Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, "timestamp", first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.

===Chips to use===
*16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)
*1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)
*1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)
*1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)

Pipe creation workflow

2009-03-03T22:55:00Z

129.42.161.36:

Creating a pipe and rank has several steps and possible intermediate file formats and editing tools.

===1: Create the spectrum for a pipe===
The spectrum needs to be created for a pipe. This can be done in octave, and then viewed in gnuplot. It could be created with a C program. It would be nice to have a javascript editor to create these a bit more dynamically so you can see what the spectrum will look like, and also to see what the the resulting pipe would sound like.

The file format for the spectrum is nice and simple, to aid in creation and use by the various tools. There is no header, just a list of records, each one holding a complex value associated with a given frequency in the response. It's likely that all frequencies from 0 up to 22050 would be present at uniform spacing, but this wouldn't be necessarily the case.
Format for each record is:
float float float
First float is the frequency in hertz, second is the real part of the DFT value at that frequency, and third is the imaginary part of the DFT value at that frequency.

All frequencies above 22050 should be chopped to prevent aliasing. File should be named as:
<rank name>_<fundamental frequency>.dft

Gnuplot can easily read this format for plotting, as can C files for later conversion. C files and octave can write this format easily.

Tools:
*octave(existing) - to create a spectrum from scratch and known theoretical concepts
*gnuplot(existing) - to display the spectrum for analysis
*nameless javascript tool - to interactively edit the spectrum
*wavdft - to convert a recording of a pipe to a spectrum file for clean up and re-dissection.

===2: Convert from spectrum to pipe waveform===
Once the spectrum is created, the pipe waveform data can be created by using FFT on the data in the spectrum file, or the slow sinusoid summation manually. Once the waveform data is generated, its normalized and using input parameters to specify envelope characteristics, appropriate subsets are taken of the waveform and placed into a pipe file, named:
<rank name>_<fundamental frequency>.pipe

The format of that file is a pipe header, specifying the fundamental frequency, the lengths of each portion of the waveform data, and arrays of floats for the sustain, attack, and release portions, is from rankfile.H

The tool that will be used to do this processing is "pipegen" which will take the .dft and some envelope parameters, and generate a .pipe file.

This pipe file can then be played back using the "playpipe" utility. Also, a "playset" utility can be used to play multiple pipes at once, for testing how a pipe set sounds together, to see how a chord in a given rank will sound, or to see how a note or chord sounds when played with multiple stops pulled.

Tools:
*pipegen - to generate a pipe file from a spectrum file
*playpipe - to listen to the pipe to make sure it sounds as expected
*playset - to listen to a set of pipes to make sure they sound good together

===3: Combine pipe files into a rank file===
The rank file will be created according to rankfile.H, consisting of a rank header, an index to find each pipe data section, and the data from each pipe data file, all combined into one rank file, with a name of form:
<rank name>_<pitch length in rounded feet>.rank

This file will be generated by "rankgen", which will take parameters to specify the name and length of this rank, as well as how many pipes are in each set, and a list of all the pipes to add to the rank, in the order to put them into the file, with each set preceded by the written note that will cause this rank to play that set of pipes.

A rankfile can be played using the "playrank" tool, which will cause each pipe set in the rank to play, one after the other. All pipes in a given set will sound simultaneously here, to get an accurate affect of what this rank will sound like when played on the organ. A "playbar" tool will take a set of ranks that should be un-stopped, and a sequence of midi notes to play using those ranks. All the notes will use the ranks specified.

Tools:
*rankgen - to generate the rank file from the given sets of pipes
*playrank - to listen to all the pipes of a rank to verify they all sound alike and of similar volumes and timbres.
*playbar - to listen to a simple midi sequence on a given set of ranks to make sure we are interpreting notes correctly.

===4: Play the organ===
Once all the ranks are complete, "organ-emu" would listen for midi events from the organ and play the right pipes from the right ranks for each division. "midi-test" just listens for midi events from the organ and displays them on screen, or records them to a file. "organ-midi" is similar to "playbar" in that it takes in a midi file, but this will interpret stop keys correctly, and set the proper ranks on for each manual/pedal, and interpret the midi channels correctly to play back the song using the full organ abilities.

Tools:
*midi-test - to listen to midi events from the organ and display or record them
*organ-midi - to playback a recorded stream of midi events for the organ, including stops and multiple divisions
*organ-emu - to listen for midi events and play the resulting ranks and pipes in real-time.

Pipe creation workflow

2009-03-03T22:54:08Z

129.42.161.36:

Creating a pipe and rank has several steps and possible intermediate file formats and editing tools.

===1: Create the spectrum for a pipe===
The spectrum needs to be created for a pipe. This can be done in octave, and then viewed in gnuplot. It could be created with a C program. It would be nice to have a javascript editor to create these a bit more dynamically so you can see what the spectrum will look like, and also to see what the the resulting pipe would sound like.

The file format for the spectrum is nice and simple, to aid in creation and use by the various tools. There is no header, just a list of records, each one holding a complex value associated with a given frequency in the response. It's likely that all frequencies from 0 up to 22050 would be present at uniform spacing, but this wouldn't be necessarily the case.
Format for each record is:
float float float
First float is the frequency in hertz, second is the real part of the DFT value at that frequency, and third is the imaginary part of the DFT value at that frequency.

All frequencies above 22050 should be chopped to prevent aliasing. File should be named as:
<rank name>_<fundamental frequency>.dft

Gnuplot can easily read this format for plotting, as can C files for later conversion. C files and octave can write this format easily.

Tools:
*octave - to create a spectrum from scratch and known theoretical concepts
*nameless javascript tool - to interactively edit the spectrum
*gnuplot - to display the spectrum for analysis
*wavdft - to convert a recording of a pipe to a spectrum file for clean up and re-dissection.

===2: Convert from spectrum to pipe waveform===
Once the spectrum is created, the pipe waveform data can be created by using FFT on the data in the spectrum file, or the slow sinusoid summation manually. Once the waveform data is generated, its normalized and using input parameters to specify envelope characteristics, appropriate subsets are taken of the waveform and placed into a pipe file, named:
<rank name>_<fundamental frequency>.pipe

The format of that file is a pipe header, specifying the fundamental frequency, the lengths of each portion of the waveform data, and arrays of floats for the sustain, attack, and release portions, is from rankfile.H

The tool that will be used to do this processing is "pipegen" which will take the .dft and some envelope parameters, and generate a .pipe file.

This pipe file can then be played back using the "playpipe" utility. Also, a "playset" utility can be used to play multiple pipes at once, for testing how a pipe set sounds together, to see how a chord in a given rank will sound, or to see how a note or chord sounds when played with multiple stops pulled.

Tools:
*pipegen - to generate a pipe file from a spectrum file
*playpipe - to listen to the pipe to make sure it sounds as expected
*playset - to listen to a set of pipes to make sure they sound good together

===3: Combine pipe files into a rank file===
The rank file will be created according to rankfile.H, consisting of a rank header, an index to find each pipe data section, and the data from each pipe data file, all combined into one rank file, with a name of form:
<rank name>_<pitch length in rounded feet>.rank

This file will be generated by "rankgen", which will take parameters to specify the name and length of this rank, as well as how many pipes are in each set, and a list of all the pipes to add to the rank, in the order to put them into the file, with each set preceded by the written note that will cause this rank to play that set of pipes.

A rankfile can be played using the "playrank" tool, which will cause each pipe set in the rank to play, one after the other. All pipes in a given set will sound simultaneously here, to get an accurate affect of what this rank will sound like when played on the organ. A "playbar" tool will take a set of ranks that should be un-stopped, and a sequence of midi notes to play using those ranks. All the notes will use the ranks specified.

Tools:
*rankgen - to generate the rank file from the given sets of pipes
*playrank - to listen to all the pipes of a rank to verify they all sound alike and of similar volumes and timbres.
*playbar - to listen to a simple midi sequence on a given set of ranks to make sure we are interpreting notes correctly.

===4: Play the organ===
Once all the ranks are complete, "organ-emu" would listen for midi events from the organ and play the right pipes from the right ranks for each division. "midi-test" just listens for midi events from the organ and displays them on screen, or records them to a file. "organ-midi" is similar to "playbar" in that it takes in a midi file, but this will interpret stop keys correctly, and set the proper ranks on for each manual/pedal, and interpret the midi channels correctly to play back the song using the full organ abilities.

Tools:
*midi-test - to listen to midi events from the organ and display or record them
*organ-midi - to playback a recorded stream of midi events for the organ, including stops and multiple divisions
*organ-emu - to listen for midi events and play the resulting ranks and pipes in real-time.

Pipe creation workflow

2009-03-03T22:48:08Z

129.42.161.36:

Creating a pipe and rank has several steps and possible intermediate file formats and editing tools.

===1: Create the spectrum for a pipe===
The spectrum needs to be created for a pipe. This can be done in octave, and then viewed in gnuplot. It could be created with a C program. It would be nice to have a javascript editor to create these a bit more dynamically so you can see what the spectrum will look like, and also to see what the the resulting pipe would sound like.

The file format for the spectrum is nice and simple, to aid in creation and use by the various tools. There is no header, just a list of records, each one holding a complex value associated with a given frequency in the response. It's likely that all frequencies from 0 up to 22050 would be present at uniform spacing, but this wouldn't be necessarily the case.
Format for each record is:
float float float
First float is the frequency in hertz, second is the real part of the DFT value at that frequency, and third is the imaginary part of the DFT value at that frequency.

All frequencies above 22050 should be chopped to prevent aliasing. File should be named as:
<rank name>_<fundamental frequency>.dft

Gnuplot can easily read this format for plotting, as can C files for later conversion. C files and octave can write this format easily.

===2: Convert from spectrum to pipe waveform===
Once the spectrum is created, the pipe waveform data can be created by using FFT on the data in the spectrum file, or the slow sinusoid summation manually. Once the waveform data is generated, its normalized and using input parameters to specify envelope characteristics, appropriate subsets are taken of the waveform and placed into a pipe file, named:
<rank name>_<fundamental frequency>.pipe

The format of that file is a pipe header, specifying the fundamental frequency, the lengths of each portion of the waveform data, and arrays of floats for the sustain, attack, and release portions, is from rankfile.H

The tool that will be used to do this processing is "pipegen" which will take the .dft and some envelope parameters, and generate a .pipe file.

This pipe file can then be played back using the "playpipe" utility. Also, a "playset" utility can be used to play multiple pipes at once, for testing how a pipe set sounds together, to see how a chord in a given rank will sound, or to see how a note or chord sounds when played with multiple stops pulled.

===3: Combine pipe files into a rank file===
The rank file will be created according to rankfile.H, consisting of a rank header, an index to find each pipe data section, and the data from each pipe data file, all combined into one rank file, with a name of form:
<rank name>_<pitch length in rounded feet>.rank

This file will be generated by "rankgen", which will take parameters to specify the name and length of this rank, as well as how many pipes are in each set, and a list of all the pipes to add to the rank, in the order to put them into the file, with each set preceded by the written note that will cause this rank to play that set of pipes.

A rankfile can be played using the "playrank" tool, which will cause each pipe set in the rank to play, one after the other. All pipes in a given set will sound simultaneously here, to get an accurate affect of what this rank will sound like when played on the organ. A "playbar" tool will take a set of ranks that should be un-stopped, and a sequence of midi notes to play using those ranks. All the notes will use the ranks specified.

===4: Play the organ===
Once all the ranks are complete, "organ-emu" would listen for midi events from the organ and play the right pipes from the right ranks for each division. "midi-test" just listens for midi events from the organ and displays them on screen, or records them to a file. "organ-midi" is similar to "playbar" in that it takes in a midi file, but this will interpret stop keys correctly, and set the proper ranks on for each manual/pedal, and interpret the midi channels correctly to play back the song using the full organ abilities.

Pipe creation workflow

2009-03-03T22:47:26Z

129.42.161.36: New page: Creating a pipe and rank has several steps and possible intermediate file formats and editing tools. ===1: Create the spectrum for a pipe=== The spectrum needs to be created for a pipe. ...

Creating a pipe and rank has several steps and possible intermediate file formats and editing tools.

===1: Create the spectrum for a pipe===
The spectrum needs to be created for a pipe. This can be done in octave, and then viewed in gnuplot. It could be created with a C program. It would be nice to have a javascript editor to create these a bit more dynamically so you can see what the spectrum will look like, and also to see what the the resulting pipe would sound like.

The file format for the spectrum is nice and simple, to aid in creation and use by the various tools. There is no header, just a list of records, each one holding a complex value associated with a given frequency in the response. It's likely that all frequencies from 0 up to 22050 would be present at uniform spacing, but this wouldn't be necessarily the case.
Format for each record is:
float float float
First float is the frequency in hertz, second is the real part of the DFT value at that frequency, and third is the imaginary part of the DFT value at that frequency.

All frequencies above 22050 should be chopped to prevent aliasing. File should be named as:
<rank name>_<fundamental frequency>.dft

Gnuplot can easily read this format for plotting, as can C files for later conversion. C files and octave can write this format easily.

===2: Convert from spectrum to pipe waveform===
Once the spectrum is created, the pipe waveform data can be created by using FFT on the data in the spectrum file, or the slow sinusoid summation manually. Once the waveform data is generated, its normalized and using input parameters to specify envelope characteristics, appropriate subsets are taken of the waveform and placed into a pipe file, named:
<rank name>_<fundamental frequency>.pipe

The format of that file is a pipe header, specifying the fundamental frequency, the lengths of each portion of the waveform data, and arrays of floats for the sustain, attack, and release portions, is from rankfile.H

The tool that will be used to do this processing is "pipegen" which will take the .dft and some envelope parameters, and generate a .pipe file.

This pipe file can then be played back using the "playpipe" utility. Also, a "playset" utility can be used to play multiple pipes at once, for testing how a pipe set sounds together, to see how a chord in a given rank will sound, or to see how a note or chord sounds when played with multiple stops pulled.

===3: Combine pipe files into a rank file===
The rank file will be created according to rankfile.H, consisting of a rank header, an index to find each pipe data section, and the data from each pipe data file, all combined into one rank file.

This file will be generated by "rankgen", which will take parameters to specify the name and length of this rank, as well as how many pipes are in each set, and a list of all the pipes to add to the rank, in the order to put them into the file, with each set preceded by the written note that will cause this rank to play that set of pipes.

A rankfile can be played using the "playrank" tool, which will cause each pipe set in the rank to play, one after the other. All pipes in a given set will sound simultaneously here, to get an accurate affect of what this rank will sound like when played on the organ. A "playbar" tool will take a set of ranks that should be un-stopped, and a sequence of midi notes to play using those ranks. All the notes will use the ranks specified.

===4: Play the organ===
Once all the ranks are complete, "organ-emu" would listen for midi events from the organ and play the right pipes from the right ranks for each division. "midi-test" just listens for midi events from the organ and displays them on screen, or records them to a file. "organ-midi" is similar to "playbar" in that it takes in a midi file, but this will interpret stop keys correctly, and set the proper ranks on for each manual/pedal, and interpret the midi channels correctly to play back the song using the full organ abilities.

MIDI and the organ project

2009-03-03T19:49:57Z

129.42.161.36:

*[http://sessrumnir.net/organs/trunk/ SVN trunk for organ code]
*[http://www.die-orgelseite.de/pfeifenarten_e.htm Interesting site for pipe shapes and sounds]

*[[Pipe creation workflow]]

====MIDI and the organ====
MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.

The basics, as I think we will be using them:

Packet basics (we'll only be using 3 byte packet forms):

1 <3: opcode> <4: channel> 0 <7: arg1> 0 <7: arg2>

Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).

opcodes of relevance:
*0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.
*0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.
*0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)

For channels, we will use:
*0x0: Great (Solo) Manual
*0x1: Swell (Accompaniment) Manual
*0x2: Choir (below Great) Manual, if present
*0x3: Solo (above Swell) Manual, if present
*0x4: Echo (above Solo) Manual, if present
*0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.
*0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.
*0x7: Main Pedalboard
*0x8: Great stops only
*0x9: Swell stops only
*0xA: Choir stops only
*0xB: Solo stops only
*0xC: Echo stops only
*0xD: Third Pedalboard stops only
*0xE: Second Pedalboard stops only
*0xF: Main Pedalboard stops only

Our initial organ will only use channels 0x0-0x1, 0x6-0x7.

Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It'd be kinda a lot harder to make work right, I think.

We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi's numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.

Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don't even need to populate the board positions for the other channel boards.

Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don't need a pin for ground or power, I don't think... Though if there is room, I guess we could send it along there, too. Can't hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.

Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.

===Simple algorithm for key change detection===
After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor'ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don't have to analyze it, it hasn't changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.

Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.

Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, "timestamp", first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.

===Chips to use===
*16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)
*1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)
*1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)
*1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)

MIDI and the organ project

2009-03-02T17:58:25Z

129.42.161.36:

*[http://sessrumnir.net/organs/trunk/ SVN trunk for organ code]
*[http://www.die-orgelseite.de/pfeifenarten_e.htm Interesting site for pipe shapes and sounds]

====MIDI and the organ====
MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.

The basics, as I think we will be using them:

Packet basics (we'll only be using 3 byte packet forms):

1 <3: opcode> <4: channel> 0 <7: arg1> 0 <7: arg2>

Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).

opcodes of relevance:
*0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.
*0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.
*0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)

For channels, we will use:
*0x0: Great (Solo) Manual
*0x1: Swell (Accompaniment) Manual
*0x2: Choir (below Great) Manual, if present
*0x3: Solo (above Swell) Manual, if present
*0x4: Echo (above Solo) Manual, if present
*0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.
*0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.
*0x7: Main Pedalboard
*0x8: Great stops only
*0x9: Swell stops only
*0xA: Choir stops only
*0xB: Solo stops only
*0xC: Echo stops only
*0xD: Third Pedalboard stops only
*0xE: Second Pedalboard stops only
*0xF: Main Pedalboard stops only

Our initial organ will only use channels 0x0-0x1, 0x6-0x7.

Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It'd be kinda a lot harder to make work right, I think.

We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi's numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.

Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don't even need to populate the board positions for the other channel boards.

Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don't need a pin for ground or power, I don't think... Though if there is room, I guess we could send it along there, too. Can't hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.

Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.

===Simple algorithm for key change detection===
After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor'ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don't have to analyze it, it hasn't changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.

Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.

Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, "timestamp", first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.

===Chips to use===
*16x? 74HCT540 for the octal tri-state buffers, inverting (0.54, 20 pin dip)
*1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)
*1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)
*1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)

MIDI and the organ project

2009-02-23T19:34:56Z

129.42.161.36:

MIDI standard is out there. Also good is the RTP-MIDI RFC, for putting MIDI data into a stream and whatnot.

The basics, as I think we will be using them:

Packet basics (we'll only be using 3 byte packet forms):

1 <3: opcode> <4: channel> 0 <7: arg1> 0 <7: arg2>

Essentially, a status byte, with the high bit on (0x80-0xFF), and two argument bytes, with the high bit off (0x00-0x7F).

opcodes of relevance:
*0x0: key off. arg1 is the key number, arg2 is the velocity. We will always use velocity of 0x40.
*0x1: key on. arg1 is the key number, arg2 is the velocity. We will always use the velocity of 0x40.
*0x3: control change. arg1 is the control number (0x01 is modulation wheel, 0x0B is the expression pedal), arg2 is the new control value, from 0x00 - 0x7F (Note: If we need more than 127 steps, add 0x20 to the control number, and thats the control number to use to send the least significant 7-bits of the value. The value sent with the base control number is considered to be the most significant 7-bits of the value. This ensures that if just read the base control number, you set the control to approximately the correct percentage of fully off/fully on.)

For channels, we will use:
*0x0: Great (Solo) Manual
*0x1: Swell (Accompaniment) Manual
*0x2: Choir (below Great) Manual, if present
*0x3: Solo (above Swell) Manual, if present
*0x4: Echo (above Solo) Manual, if present
*0x5: Third Pedalboard, if present, or the auxilary stop channel, covering additional stops for all manuals and pedals.
*0x6: Second Pedalboard, if present, or the main stop channel, covering all stops for all manuals and pedals.
*0x7: Main Pedalboard
*0x8: Great stops only
*0x9: Swell stops only
*0xA: Choir stops only
*0xB: Solo stops only
*0xC: Echo stops only
*0xD: Third Pedalboard stops only
*0xE: Second Pedalboard stops only
*0xF: Main Pedalboard stops only

Our initial organ will only use channels 0x0-0x1, 0x6-0x7.

Each keyboard channel (0x0-0x7) gets its own control set. For our organ, where the modulation wheel and expression pedal control all divisions equally, each control change gets sent for each active channel... or maybe just for great, and the software will figure out that they control all the stuff. Note, we may not hook up the modulation wheel when we begin. It'd be kinda a lot harder to make work right, I think.

We will be building channel combination boards, that take an enable and a sub-channel address, and read back the contents of the addressed buffer. 4 bits of address gets 16 buffers. At 8 bits per buffer, thats 128 inputs for each channel. That matches with midi's numbering scheme. Alternatively, if you take the LSB of the true channel, and feed it to the 4th address bit of the channel board, and only decode the top 3 bits of the channel to determine channel board enable, you can duplex your channel boards, since we will only be using under 64 inputs per channel. The AVR firmware will have an MIDI offset value for each channel to add to the number received from the board before sending as part of a MIDI command. For most subchannels, this will be 36. Will probably just use an offset of 0 for the stop channels.

Using the split channel board design, we only need two channel boards for our organ. The main board will be designed to use the channel boards in split mode, and will never probably use the split-mode stop channels (0x8-0xF), so it will only have 4 plugs for channel boards, 0x0-0x1, 0x2-0x3, 0x4-0x5, and 0x6-0x7. The initial organ will only use the first and last of these plugs, so we don't even need to populate the board positions for the other channel boards.

Also, I think we might want to put all the switch pull-up resistors on the manuals themselves, soldered to the key tabs. This will eliminate a lot of crap on the boards, and keep the board design uniform, since the different keys will need different pull-ups. The manuals, with their 5k internal resistance, will need 50k (or so) pull-ups to 5V, and the pedals and stops, with no internal resistance, will need just 10k (or so) pull-ups to 5V. Each manual will get a separate power and ground plug for the pull-ups and grounds, so the connectors for the keys don't need a pin for ground or power, I don't think... Though if there is room, I guess we could send it along there, too. Can't hurt anything, provided the wires support enough current for the crazy case of all the stop pulled or keys pressed or something. Given a max of 64 inputs to a half-channel, and only 61 keys on a full manual, we can use 2x36 pin connectors for the manuals, and 1x36 pin connector for the pedalboards, and 1x36 pin connector for the stop boards. Thats 6 total 36 pin connectors, male and female, solder cup and through-hole.

Channel board to main board connectors will have an 8-bit data bus, 4-bit address bus, a power, ground, enable, and identify(?) pins (16 total). Should be able to use IDC connectors and ribbon cable here.

===Simple algorithm for key change detection===
After reading a byte from the buffers, we xor it with the copy of the byte from last time, then store the new version in the copy location. We then start looking at the lsb of the xor'ed byte. If its a 1, we send a key on if the lsb of the read byte is a 1, and a key off if the lsb of the read byte is a 0. We then shift right and do that again. We do that 8 times, once for each bit in that byte. Then we can move on to the next valid address for that channel, write out the address, read back the buffer value, xor, store, analyze, etc. Note, we can speed this up by checking if the xor byte is identically 0x00, in which case we don't have to analyze it, it hasn't changed. This will be the usual case! Only occasionally (in sample time), will things change, and usually only on one bit, and thus one buffer, amongst all the channels and buffers. This should help us keep up to speed.

Once we are done reading all the channel board buffers, we can check the expression pedals and other variable controls for new values, and possibly send control change events. After all this, we actually send the MIDI bytes as we have determined them to need to be for this time around, and go to sleep until our next sample time.

Not sure what the latency of the serial to USB conversion is in FTDI, but it could be as bad as a single byte in a single USB message.... Anyway, we want to build a buffer of bytes that need to get send over each sample time, with the RTP-MIDI spec used to make it a stream type thing. This means: packet length, "timestamp", first MIDI event, relative timestamps (should all be zero), subsequent MIDI events.

===Chips to use===
*16x? 74HCT541 for the octal tri-state buffers (0.40, 20 pin dip)
*1x? 74HCT138 for 1 to 8 decoder (0.40, 16 pin dip)
*1x? 74HCT154 for 1 to 16 decoder (0.80, 24 pin dip)
*1x ATMega164P-20P for AVR controller, 20MHz, (4.82, 40 pin dip)

Thoughts on avr event scheduling

2009-01-30T00:35:56Z

129.42.161.36:

For my reprap playground firmware, I need a better way to schedule events. This will enable me to do g-code shorthand movement calls. The general form will be
int moveVect(dx, dy, dz, rampUpTime, initialSpeed, finalSpeed, rampDownTime)
dx, dy, dz is the motion vector relative to current position, given in mm. rampUpTime and rampDownTime are given in seconds, and initialSpeed/finalSpeed are given in mm/s. moveVect returns 0 if we were able to move all the way to the target location. It returns 1 if we could not move all the way there because we hit an endstop. It returns 2 if we could not move all the way there because we think we would have hit another edge (no endstop).

To help us, we need to have steps per mm numbers for each axis (qx, qy, qz). We also should have a stepping interval time (qt). This is how long to actually have the motor coil energized. This should either be small enough to run during the event, or large enough that a new event to de-energize can be scheduled and run.

As we run through the moveVect() we determine a current speed by linearizing from 0 to initialSpeed over the rampUpTime interval, then linearizing to the finalSpeed over a calculated time it will take us to move in toto (could be tough..??), and finally linearizing back down to 0 over rampDownTime. After getting the current speed (s), we find out velocity vector (v) by normalizing the motion vector and multiplying it by the speed.
dh = sqrt(dx^2 + dy^2 + dz^2)
v = (dx*s/dh, dy*s/dh, dz*s/dh)

The next step events should be scheduled then at times in the future given by
1/(vi*qi) - qt
for each axis. This event simply steps the given axis by toggling the step line for qt seconds.

Each step event needs an axis and a direction. Associated with each move is a move control block, containing velocity vector information, acceleration vector information, and target location data, as well as info about if we stopped, and why.
At each event, we check endstops and position to determine if we have to stop, otherwise, we step, adjust that axis's velecity information using the acceleration information for that axis, and schedule the next event for that axis.

We can chain moves together in a list, and when one move is finished (all axis event chains have ceased, or we are on the last one), we pull up the next move control block and trigger its event chains for each axis.

We'll need to use one of the chip's timers for our interrupt, and the interrupt should look at the next event in the event list, and if its timer has expired or will expire, we execute it and remove it from the list. We then look at the next event in the list. If its timer has now expired, we execute that one too. We keep doing this until we have no more events or we find one that needs to execute in the future. We set our interrupt for that future time and exit.

When somebody schedules a new event, we determine if the new event should fire after or before the first one in our current list. If before, we put it in the list before the first item and reset the interrupt trigger time to our new event's time. If after, we put it in the list in the right spot and call it good.

Scheduling an event and the checking to see if we need to run an event need to occur under an event list lock, so we don't mess up our event list or the timer. Just use a spin lock probably, and enable/disable interrupts around our check and set.

== Move List ==
move list lock, next move ptr, next available id, plus list of move control blocks, each containing:
type = 1(move)
id
status 0 not yet active, 1 in progress, 2 complete, at target, 3 complete, not at target
link to next move
x,y,z endstop/position status (0, ok, 1 max endstop, 2 min endstop, 3 max steps, 4 min steps)
x,y,z target
x,y,z velocity (current)
x,y,z acceleration
link to next move

type = 2(dwell)
id
status 0 not yet active, 1 in progress, 2 completed.
link to next move
dwell time

When a move is completed, the old move control block is left on the list until it is removed (to check status, etc), but the next move in the list is started up immediately. Some move functions:
mid = moveDelta(dx, dy, dz, initial speed, final speed)
mid = moveTo(x, y, z, initial speed, final speed)
status = cancelMove(mid)
mid = moveDwell(dwell time)
void genMcb(delta?, x,y,z, ispeed, fspeed, buffer*)

== Event Queue ==
event queue lock, next event ptr, next available id, plus list of event control blocks currently scheduled
type = 0 nop
time to fire
id
link to next event
move after?

type = 1 step
time to fire
id
link to next event
axis
move control block ptr

type = 2 run
time to fire
id
link to next event
function ptr to call (of type (void)(void*))
ptr to pass to function when run

type = 3 move
time to fire
id
link to next event
number of mcbs in this event
move control blocks to run in the future

When an event is triggered, the event is discarded after being run. Some event functions:
eid = scheduleEvent(type, delta time, data ptr, data len) (eid = -1 means couldn't schedule)
status = cancelEvent(eid) (status = -1 means no such event)
eid = scheduleFunction(delta time, func ptr, data)
eid = scheduleMoveSequence(delta time, num moves, mcb*)
eid = scheduleNop(delta time, move after?)

Thoughts on avr event scheduling

2009-01-30T00:23:38Z

129.42.161.36:

For my reprap playground firmware, I need a better way to schedule events. This will enable me to do g-code shorthand movement calls. The general form will be
int moveVect(dx, dy, dz, rampUpTime, initialSpeed, finalSpeed, rampDownTime)
dx, dy, dz is the motion vector relative to current position, given in mm. rampUpTime and rampDownTime are given in seconds, and initialSpeed/finalSpeed are given in mm/s. moveVect returns 0 if we were able to move all the way to the target location. It returns 1 if we could not move all the way there because we hit an endstop. It returns 2 if we could not move all the way there because we think we would have hit another edge (no endstop).

To help us, we need to have steps per mm numbers for each axis (qx, qy, qz). We also should have a stepping interval time (qt). This is how long to actually have the motor coil energized. This should either be small enough to run during the event, or large enough that a new event to de-energize can be scheduled and run.

As we run through the moveVect() we determine a current speed by linearizing from 0 to initialSpeed over the rampUpTime interval, then linearizing to the finalSpeed over a calculated time it will take us to move in toto (could be tough..??), and finally linearizing back down to 0 over rampDownTime. After getting the current speed (s), we find out velocity vector (v) by normalizing the motion vector and multiplying it by the speed.
dh = sqrt(dx^2 + dy^2 + dz^2)
v = (dx*s/dh, dy*s/dh, dz*s/dh)

The next step events should be scheduled then at times in the future given by
1/(vi*qi) - qt
for each axis. This event simply steps the given axis by toggling the step line for qt seconds.

Each step event needs an axis and a direction. Associated with each move is a move control block, containing velocity vector information, acceleration vector information, and target location data, as well as info about if we stopped, and why.
At each event, we check endstops and position to determine if we have to stop, otherwise, we step, adjust that axis's velecity information using the acceleration information for that axis, and schedule the next event for that axis.

We can chain moves together in a list, and when one move is finished (all axis event chains have ceased, or we are on the last one), we pull up the next move control block and trigger its event chains for each axis.

We'll need to use one of the chip's timers for our interrupt, and the interrupt should look at the next event in the event list, and if its timer has expired or will expire, we execute it and remove it from the list. We then look at the next event in the list. If its timer has now expired, we execute that one too. We keep doing this until we have no more events or we find one that needs to execute in the future. We set our interrupt for that future time and exit.

When somebody schedules a new event, we determine if the new event should fire after or before the first one in our current list. If before, we put it in the list before the first item and reset the interrupt trigger time to our new event's time. If after, we put it in the list in the right spot and call it good.

Scheduling an event and the checking to see if we need to run an event need to occur under an event list lock, so we don't mess up our event list or the timer. Just use a spin lock probably, and enable/disable interrupts around our check and set.

== Move List ==
move list lock, next move ptr, next available id, plus list of move control blocks, each containing:
type = 1(move)
id
status 0 not yet active, 1 in progress, 2 complete, at target, 3 complete, not at target
link to next move
x,y,z endstop/position status (0, ok, 1 max endstop, 2 min endstop, 3 max steps, 4 min steps)
x,y,z target
x,y,z velocity (current)
x,y,z acceleration
link to next move

type = 2(dwell)
id
status 0 not yet active, 1 in progress, 2 completed.
link to next move
dwell time

== Event Queue ==
event queue lock, next event ptr, next available id, plus list of event control blocks currently scheduled
type = 0 nop
time to fire
id
link to next event

type = 1 step
time to fire
id
link to next event
axis
move control block ptr

type = 2 run
time to fire
id
link to next event
function ptr to call (of type (void)(void*))
ptr to pass to function when run

type = 3 move
time to fire
id
link to next event
move control block to run execute in the future

MimeEntity

2009-01-23T00:52:19Z

129.42.161.36:

MimeEntity represents a standard [[MIME]]/HTTP entity, including headers and body. For [[Modjs]], there is a MimeEntity in [[MailMessage]]s, [[HTTPRequest]]s, and [[HTTPResponse]]s, including the request that brought about the modjs script invocation, and the response that will be sent back.

MimeEntitys can be created manually with:
entity = new MimeEntity(array of [[MimeHeader]]s, body)

If this doesn't work for some reason, it could throw
MimeEntityException

Each MimeEntity has the following properties, which may be queried, but really shouldn't be edited directly.
*headers: the array of [[MimeHeader]]s for this entity
*body: the raw body of this entity
*type: the major content type of this entity
*subtype: the subtype of this entity
*id: the content-id of this entity, if it has one
*boundary: the boundary string of this entity
*children: an array of MimeEntities representing the children of this entity, in the multipart and message types
*leader: In a multipart or message entity, the part of the body before the first boundary
*trailer: In a multipart or message entity, the part of the body after the last boundary

The entity also has the following methods, which should be the primary method of modifying the entity if needed.
string = entity.toString()
string = entity.getContentType()
string = entity.getBoundaryString(last?)
entity.addHeader([[MimeHeader]] | array of [[MimeHeader]]s)
string = entity.getHeader(name)
entity.setHeader(name, value)
entity.clearBody()
entity.setBody(string)
entity.addToBody(string)
entity.addMessageEntity(MimeEntity)
entity.addMultipartEntity(MimeEntity | array of MimeEntitys)
MimeEntity = entity.removeChildEntity(index)
MimeEntity = entity.getChildEntity(index)
MimeEntity = entity.getChildEntityById(id)

MimeEntity

2009-01-23T00:49:36Z

129.42.161.36:

MimeEntity represents a standard [[MIME]]/HTTP entity, including headers and body. For [[Modjs]], there is a MimeEntity in MailMessages, HTTPRequests, and HTTPResponses, including the request that brought about the modjs script invocation, and the response that will be sent back.

MimeEntitys can be created manually with:
entity = new MimeEntity(array of MimeHeaders, body)

If this doesn't work for some reason, it could throw
MimeEntityException

Each MimeEntity has the following properties, which may be queried, but really shouldn't be edited directly.
*headers: the array of MimeHeaders for this entity
*body: the raw body of this entity
*type: the major content type of this entity
*subtype: the subtype of this entity
*id: the content-id of this entity, if it has one
*boundary: the boundary string of this entity
*children: an array of MimeEntities representing the children of this entity, in the multipart and message types
*leader: In a multipart or message entity, the part of the body before the first boundary
*trailer: In a multipart or message entity, the part of the body after the last boundary

The entity also has the following methods, which should be the primary method of modifying the entity if needed.
string = entity.toString()
string = entity.getContentType()
string = entity.getBoundaryString(last?)
entity.addHeader(MimeHeader | array of MimeHeader)
string = entity.getHeader(name)
entity.setHeader(name, value)
entity.clearBody()
entity.setBody(string)
entity.addToBody(string)
entity.addMessageEntity(MimeEntity)
entity.addMultipartEntity(MimeEntity | array of MimeEntitys)
MimeEntity = entity.removeChildEntity(index)
MimeEntity = entity.getChildEntity(index)
MimeEntity = entity.getChildEntityById(id)

HTTPRequest

2009-01-23T00:48:23Z

129.42.161.36: New page: The HTTPRequest class represents an HTTP Request message for my Modjs environment. It contains a request line and other information about the requestor, and a MIME entity ([[MimeE...

The HTTPRequest class represents an HTTP Request message for my [[Modjs]] environment. It contains a request line and other information about the requestor, and a [[MIME]] entity ([[MimeEntity]]) for the request headers and data. Its primary use will be for the script writer to see the request from the browser to the server, and what data they are sending over. It will do a little bit to parse out cookie variables, query variables, and post data variables to make the script writer's life easier. It can also be tied back to a [[HTTPResponse]] object to make inclusion of cookie headers mostly seemless when new cookies are defined and the response is sent back with them.

When a [[Modjs]] script builds a completely new HTTPRequest object in order to send it over a [[TCPConnection]] or the like to a different, remote, server, it will behave a little bit differently, in that, rather than parsing the headers and request data in order to get cookies/queries/posts, it will have the ability to unparse those variables sets back into headers and request data, as needed (and only if requested). And not cookies. Just too much work for too little benefit.

Some info on this class was previously described in [[request API]], but that is no longer trustworthy and should get copied over here and corrected.

To create a new HTTPRequest object, the constructor is called:
request = new HTTPRequest(host [,method [,path [,query [,version]]]])

Note that except for host, the rest of the arguments could be passed as one string. They are essentially joined and reparsed to verify that the correct syntax is used for the request line. host sets the required Host: header in the mimeentity on creation. If the method is POST, the Content-type: header also gets set to the default value of application/form-data.

This could throw an exception if method or query string are malformed:
HTTPRequestException

The object will have these properties:
*method: the request method
*path: the request path
*query: the request query
*host: the request host
*version: the request version
*entity: the [[MimeEntity]] for the data in this request, including headers.
*queryVars: the query is parsed and proper variables are put in here as name/value pairs. Last one sticks. If you reuse a name, you'll have to go to the real query to get both values. On outgoing requests, this will get slurped up and urlencoded and _added_ to the query property as part of the query string in the request line. Be aware!
*cookieVars: the Cookie and Cookie2 headers are parsed and proper variables are put in here as name/value pairs. If there are duplicate names, the last one sticks. Go to the actual headers if you need more, or property values. Note that this is not a magic cookie jar. For the outgoing response, if you need to add new cookies, you must add the cookie using the [[HTTPResponse]] addCookie() method. For outgoing requests, the cookie variables placed in here do not get magically merged into the appropriate Cookie: header, since it doesn't have enough information.
*postVars: If the method is POST and the [[MIME]] entity is correct, posted variables get parsed and put in here as name/value pairs. If there are dups, again, the last one sticks. You may have to actually decode the entity if you need more details. On outgoing requests, this will get slurped up and put as variables in the POST data, in the appropriate section, depending on current content-type and method, etc.

The object has only one method, toString() which essentially converts to a single string, appropriate for sending over a TCPConnection. This will do queryVars and postVars recombination, if there are any variables there. Be aware! It will also use proper CRLF EOLs, for network safety.
string = request.toString()

Modjs

2009-01-22T17:54:18Z

129.42.161.36:

[http://www.modjs.org modjs.org] has the rudiments of an apache module to handle server side javascript using SpiderMonkey.

SpiderMonkey [https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference APIs] and a [https://developer.mozilla.org/en/SpiderMonkey tutorial].
Apache Module [http://httpd.apache.org/dev/apidoc/ APIs] and a [http://httpd.apache.org/dev/API.html tutorial].

Would like [[MIME]] support, a global request/response object (both MIME trees I think), SQLite and MySQL support, and File IO Support (if its not already there). Also should have support for including other javascript sources. mod_js has an example for includes and some of the request/apache stuff. SpiderMonkey has an example shell that shows some support for File objects I think.

Would be nice to have libGD and/or ImageMagick support (EXIF too, if possible), as well as some sort of curl library to get to other sites to do stuff.

----
Things we should have:
*Class for MIME objects and MIME headers.
*Object with server info (environment, log functionality)
*Object with request info (request string (full and broken up), incoming mime object, maybe cookies already broken up, etc.)
*Object with response info (outgoing mime object, print functionality, obstack stuff, way to set headers, etc)
*File class extensions, if needed
*Better include support (add to File)
*MySQL/SQLite classes and support (new classes probably needed here)
*system call support (put this on server)
*image manipulation support (new classes probably needed here)
*json support (maybe just some quick functions on the response (encode) /request (decode) ? or maybe better as a global)
*curl support (new class probably, using MIME stuff to send and receive, probably wrapped by request/response like objects.. maybe they should be classes, too.)
*Instead of bothering with curl, maybe just have a way to open a socket and read/write to it for now.

JS Class APIs:
*File (see [[File API]])
*server object (see [[server API]])
*[[TCPConnection]]
*[[DbConnection]]
*DbStatement (see [[DbConnection]])
*[[ProcessConnection]]
*[[MimeHeader]]
*[[MimeEntity]]
*[[MailMessage]]
*[[HTTPRequest]] modified [[request API]]
*[[HTTPResponse]] modified [[response API]]
*global object (see [[global object extensions]])

Things the module should do if it can:
*Cache compiled javascript code?
*Stay alive? Might already do this...
*Cached javascript context? Would this make sense?
*Cached session stuff? Do I really want/need this?

MimeEntity

2009-01-22T00:37:36Z

129.42.161.36: New page: MimeEntity represents a standard MIME/HTTP entity, including headers and body. For Modjs, there is a MimeEntity in MailMessages, HTTPRequests, and HTTPResponses, including the req...

MimeEntity represents a standard [[MIME]]/HTTP entity, including headers and body. For [[Modjs]], there is a MimeEntity in MailMessages, HTTPRequests, and HTTPResponses, including the request that brought about the modjs script invocation, and the response that will be sent back.

MimeEntitys can be created manually with:
entity = new MimeEntity(array of MimeHeaders, body)

If this doesn't work for some reason, it could throw
MimeEntityException

Each MimeEntity has the following properties, which may be queried, but really shouldn't be edited directly.
*headers: the array of MimeHeaders for this entity
*body: the raw body of this entity
*type: the major content type of this entity
*subtype: the subtype of this entity
*id: the content-id of this entity, if it has one
*boundary: the boundary string of this entity
*children: an array of MimeEntities representing the children of this entity, in the multipart and message types
*leader: In a multipart or message entity, the part of the body before the first boundary
*trailer: In a multipart or message entity, the part of the body after the last boundary

The entity also has the following methods, which should be the primary method of modifying the entity if needed.
string = entity.toString()
string = entity.getContentType()
string = entity.getBoundaryString(last?)
entity.addHeader(MimeHeader | array of MimeHeader)
entity.clearBody()
entity.setBody(string)
entity.addToBody(string)
entity.addMessageEntity(MimeEntity)
entity.addMultipartEntity(MimeEntity | array of MimeEntitys)
MimeEntity = entity.removeChildEntity(index)
MimeEntity = entity.getChildEntity(index)
MimeEntity = entity.getChildEntityById(id)

MimeHeader

2009-01-22T00:17:27Z

129.42.161.36:

A MimeHeader object represents a single header in a MIME or HTTP message in a easier to use format for [[Modjs]] scripts. Each header can have an array of MimeValue objects, which can have an array of MimeProperties. The true format of these are described in [[MIME]].

To paraphrase, a true MIME header is a name:value[,value...] pair of form:
header := header-name ':' header-value CRLF
header-value := values
values := (value-exp ',')* value-exp

Each value is of form:
value-exp := real-value (';' property-exp)*
real-value := value-key ['=' value-value]

And each property then is of form:
property-exp := property-key ['=' property-value]

A new MimeHeader can be created using:
header = new MimeHeader(name, array of MimeValue objects)
header = new MimeHeader(name, raw value string)

If the header cannot be created (if the objects passed in aren't duckable to MimeValue, or the string isn't valid header value formatted), an exception can be thrown:
MimeHeaderException

A new MimeValue can be created using:
value = new MimeValue(raw value, array of MimeParameters)
value = new MimeValue(value name, value content, array of MimeParameters)
value = new MimeValue(raw value string)

These could throw:
MimeValueException

A new MimeProperty can be created using:
property = new MimeProperty(property name, property value)

Once a header is created, it has these properties:
*name: The header name
*values: array of MimeValue objects

The header has several methods:
string = header.getName()
array of MimeValues = header.getValueList()
header.addValue(MimeValue)
MimeValue = header.removeValue(index)
MimeValue = header.getValue(index)
string = header.toString()
string = header.getValue(value name)

The value has these properties:
*value: The value name, or "true" value
*content: the value content
*properties: array of parameter name/value pairs

And these methods:
string = value.getValueName()
string = value.getValueContent()
string = value.getValue()
value.setValueContent(string)
array of MimeParameters = value.getPropertyList()
value.addParameter(MimeParameter)
MimeParameter = value.removeParameter(index)
MimeParameter = value.getParameter(index)
string = value.toString()
string = value.getParameter(parameter name)

MimeParameters have these properties:
*name: the parameter name
*value: the parameter value

And these methods:
string = parm.getName()
string = parm.getValue()
parm.setValue(string)
string = parm.toString()

MimeHeader

2009-01-22T00:14:26Z

129.42.161.36:

MimeHeader

2009-01-22T00:09:10Z

129.42.161.36: New page: A MimeHeader object represents a single header in a MIME or HTTP message in a easier to use format for Modjs scripts. Each header can have an array of MimeValue objects. The true for...

A MimeHeader object represents a single header in a MIME or HTTP message in a easier to use format for [[Modjs]] scripts. Each header can have an array of MimeValue objects. The true format of these are described in [[MIME]].

To paraphrase, a true MIME header is a name:value[,value...] pair of form:
header := header-name ':' header-value CRLF
header-value := values
values := (value-exp ',')* value-exp

Each value is of form:
value-exp := real-value (';' property-exp)*
real-value := value-key ['=' value-value]
property-exp := property-key ['=' property-value]

A new MimeHeader can be created using:
header = new MimeHeader(name, array of MimeValue objects)
header = new MimeHeader(name, raw value string)

If the header cannot be created (if the objects passed in aren't duckable to MimeValue, or the string isn't valid header value formatted), an exception can be thrown:
MimeHeaderException

A new MimeValue can be created using:
value = new MimeValue(value, array of parameter name/value pairs)
value = new MimeValue(raw value string)

These could throw:
MimeValueException

Once a header is created, it has these properties:
*name: The header name
*values: array of MimeValue objects

The header has several methods:
string = header.getName()
array of value strings = header.getValueList()
header.addValue(MimeValue)
MimeValue = header.removeValue(index)
MimeValue = header.getValue(index)
string = header.toString()

The value has these properties:
*value: The "true" value
*properties: array of parameter name/value pairs

And these methods:
string = value.getValue()
array of parameters = value.getPropertyList()
value.addParameter(name, value)
{name, value} = value.removeParameter(index)
{name, value} = value.getParameter(index)
string = value.toString()
string = value.getParameter(parameter name)

Global object extensions

2009-01-21T23:50:20Z

129.42.161.36: New page: A couple functions, I didn't know where to put, but definitely wanted for my Modjs implementation, so they went onto the global object. If I can think of a better place for them, they...

A couple functions, I didn't know where to put, but definitely wanted for my [[Modjs]] implementation, so they went onto the global object. If I can think of a better place for them, they may move. This page can also list all the classes I've added and that are available and whatnot.

Used to convert an object to a JSON compliant string and back again:
string = jsonEncode(object)
object = jsonDecode(string)

These could throw exceptions if the object or string cannot be converted or is otherwise malformed:
JsonCodingException

ProcessConnection

2009-01-21T23:47:38Z

129.42.161.36:

ProcessConnection is a class to represent an external process running on the server that is started by this [[Modjs]] script and runs independently. It can be read and written to as well.

Start the process by creating a new ProcessConnection:
process = new ProcessConnection(cmd, args array)
process = new ProcessConnection(cmdandargs)
process = new ProcessConnection(File, args array)

Read and write just like for TCPConnections:
process.send(string | array of strings)
string = process.recvAll()
string = process.recvLine(chomp?)
array of strings = process.recvLines(numlines, chomp?)
bool = process.dataAvailable()

Closing the process can be done by garbage collection or explicit close():
status = process.close()

Note that close() blocks until the process ends and a status is returned. Garbage collection will do the same.

To send a signal to the process (and thus possibly killing it earlier, if needed):
process.signal(signum)

Exceptions can be thrown:
ProcessConnectionOpenError
ProcessConnectionChildClosed

DbConnection

2009-01-21T23:46:53Z

129.42.161.36:

DbConnection is used to talk to MySQL (for now) and later SQLite databases from a [[Modjs]] script.

To connect to a database, create a new object:
connection = new DbConnection(host, database, username, password, type): type is "mysql" or "sqlite" but defaults to "mysql"

Exceptions include:
DbConnectionError
DbStatementError

To use the connection to the database:
connection.close(): closes the database connection explicitly(otherwise garbage collection will do so)
statement = connection.prepare(string): creates a new prepared statement based on the passed in string
numRowsAffected = connection.execute(string): executes the given statement straight up. Please don't use unless you have to. May not be supported.
array of result objects = connection.query(string): executes the given statement straight up. Please don't use unless you have to. May not be supported.

To use DbStatements, you must first get one from the connection by preparing it. Then:
numRowsAffected = statement.execute(array of bound arguments)
array of result objects = statement.query(array of bound arguments)

Result objects are created by using the field names (or AS marked field names) wherever possible. If not possible (expression or something), the field will be named "_exp_N" where N goes from 1 on up as needed. Try to use reasonably AS clauses. it just makes it so much easier. expressions may not be supported at first.

Statements stick around until they are garbage collected.

TCPConnection

2009-01-21T23:46:18Z

129.42.161.36:

Wrapper for C socket API. Only works for now with IPv4 and TCP streams. Only client support for now as well. Just simpler. Why would a user of [[Modjs]] need server support anyway?

Construct with:
connection = new TCPConnection(remotehost, remoteport)

Exceptions:
TCPConnectionError

Send and receive with:
connection.send(string | array of strings)
string = connection.recvAll()
string = connection.recvLine(chomp?)
array of strings = connection.recvLines(numLines, chomp?)
boolean = connection.dataAvailable()

Closure is done when garbage collected, or when close() is called directly:
connection.close()

Server API

2009-01-21T23:45:46Z

129.42.161.36:

The server object is a global object representing the server interfaces for logging and environment and such in my [[Modjs]] implementation.

Data members on the global server object:
*env: array of environment variables, including standard request headers and server information

Functions on the global server object:
*logNotice(string|array of strings): function to log a notice (or a list of notices) to the server error log
*logError(string|array of strings): function to log an error (or a list of errors) to the server error log
*runCmd(cmdstring): function execute a command on the server (with the httpd daemon's permissions!) execution of the script will wait until the cmd is finished, and will return the exit status of the command.
*runCmd(cmd, array of args): same as above, but executes the given command with the arguments given in the array. arguments will be escaped or quoted as necessary
*runCmd(File, array of args): same as above, but takes the given command from the File object passed in.

File API

2009-01-21T23:44:22Z

129.42.161.36:

File is a built in class from SpiderMonkey, but its poorly documented. Going through the source code, it appears this is what we get for the interface.

Global properties of File:
*curdir (sp?):

Properties of File objects:
*length
*name
*parent
*size
...

Methods of File objects:
*new File([path])
*open()
*close()
*flush()
...

I've extended File to add an include and require and stuff for my [[Modjs]]:
*File.prototype.include(): Executes the contents of the File as a javascript script in place.
*File.prototype.require(): Executes the contents of the File as a javascript script in place, only if it has not already been executed as part of a require(). Keeps track by updating a property in the global File class object (required[])
*File.required[]: array of filenames that have already been executed by a require() call for the current script.
*File.prototype.execute(args array): Executes the File as with server.runCmd(File, args array) and returns the exit status

Modjs

2009-01-21T23:43:47Z

129.42.161.36:

[http://www.modjs.org modjs.org] has the rudiments of an apache module to handle server side javascript using SpiderMonkey.

SpiderMonkey [https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference APIs] and a [https://developer.mozilla.org/en/SpiderMonkey tutorial].
Apache Module [http://httpd.apache.org/dev/apidoc/ APIs] and a [http://httpd.apache.org/dev/API.html tutorial].

Would like [[MIME]] support, a global request/response object (both MIME trees I think), SQLite and MySQL support, and File IO Support (if its not already there). Also should have support for including other javascript sources. mod_js has an example for includes and some of the request/apache stuff. SpiderMonkey has an example shell that shows some support for File objects I think.

Would be nice to have libGD and/or ImageMagick support (EXIF too, if possible), as well as some sort of curl library to get to other sites to do stuff.

----
Things we should have:
*Class for MIME objects and MIME headers.
*Object with server info (environment, log functionality)
*Object with request info (request string (full and broken up), incoming mime object, maybe cookies already broken up, etc.)
*Object with response info (outgoing mime object, print functionality, obstack stuff, way to set headers, etc)
*File class extensions, if needed
*Better include support (add to File)
*MySQL/SQLite classes and support (new classes probably needed here)
*system call support (put this on server)
*image manipulation support (new classes probably needed here)
*json support (maybe just some quick functions on the response (encode) /request (decode) ? or maybe better as a global)
*curl support (new class probably, using MIME stuff to send and receive, probably wrapped by request/response like objects.. maybe they should be classes, too.)
*Instead of bothering with curl, maybe just have a way to open a socket and read/write to it for now.

JS Class APIs:
*File (see [[File API]])
*server object (see [[server API]])
*[[TCPConnection]]
*[[DbConnection]]
*DbStatement (see [[DbConnection]])
*[[ProcessConnection]]
*[[MimeHeader]]
*[[MimeEntity]]
*[[MailMessage]]
*[[HTTPRequest]]
*[[HTTPResponse]]
*global object (see [[global object extensions]])

Things the module should do if it can:
*Cache compiled javascript code?
*Stay alive? Might already do this...
*Cached javascript context? Would this make sense?
*Cached session stuff? Do I really want/need this?

Modjs

2009-01-21T23:41:37Z

129.42.161.36:

[http://www.modjs.org modjs.org] has the rudiments of an apache module to handle server side javascript using SpiderMonkey.

SpiderMonkey [https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference APIs] and a [https://developer.mozilla.org/en/SpiderMonkey tutorial].
Apache Module [http://httpd.apache.org/dev/apidoc/ APIs] and a [http://httpd.apache.org/dev/API.html tutorial].

Would like [[MIME]] support, a global request/response object (both MIME trees I think), SQLite and MySQL support, and File IO Support (if its not already there). Also should have support for including other javascript sources. mod_js has an example for includes and some of the request/apache stuff. SpiderMonkey has an example shell that shows some support for File objects I think.

Would be nice to have libGD and/or ImageMagick support (EXIF too, if possible), as well as some sort of curl library to get to other sites to do stuff.

----
Things we should have:
*Class for MIME objects and MIME headers.
*Object with server info (environment, log functionality)
*Object with request info (request string (full and broken up), incoming mime object, maybe cookies already broken up, etc.)
*Object with response info (outgoing mime object, print functionality, obstack stuff, way to set headers, etc)
*File class extensions, if needed
*Better include support (add to File)
*MySQL/SQLite classes and support (new classes probably needed here)
*system call support (put this on server)
*image manipulation support (new classes probably needed here)
*json support (maybe just some quick functions on the response (encode) /request (decode) ? or maybe better as a global)
*curl support (new class probably, using MIME stuff to send and receive, probably wrapped by request/response like objects.. maybe they should be classes, too.)
*Instead of bothering with curl, maybe just have a way to open a socket and read/write to it for now.

JS Class APIs:
*File (see [[File API]])
*server object (see [[server API]])
*[[TCPConnection]]
*[[DbConnection]]
*DbStatement (see [[DbStatement]])
*[[ProcessConnection]]
*[[MimeHeader]]
*[[MimeEntity]]
*[[MailMessage]]
*[[HTTPRequest]]
*[[HTTPResponse]]
*global object (see [[global object extensions]])

Things the module should do if it can:
*Cache compiled javascript code?
*Stay alive? Might already do this...
*Cached javascript context? Would this make sense?
*Cached session stuff? Do I really want/need this?

DbConnection

2009-01-21T00:19:10Z

129.42.161.36: New page: DbConnection is used to talk to MySQL (for now) and later SQLite databases. To connect to a database, create a new object: connection = new DbConnection(host, database, username, passwor...

DbConnection is used to talk to MySQL (for now) and later SQLite databases.

To connect to a database, create a new object:
connection = new DbConnection(host, database, username, password, type): type is "mysql" or "sqlite" but defaults to "mysql"

Exceptions include:
DbConnectionError
DbStatementError

To use the connection to the database:
connection.close(): closes the database connection explicitly(otherwise garbage collection will do so)
statement = connection.prepare(string): creates a new prepared statement based on the passed in string
numRowsAffected = connection.execute(string): executes the given statement straight up. Please don't use unless you have to. May not be supported.
array of result objects = connection.query(string): executes the given statement straight up. Please don't use unless you have to. May not be supported.

To use DbStatements, you must first get one from the connection by preparing it. Then:
numRowsAffected = statement.execute(array of bound arguments)
array of result objects = statement.query(array of bound arguments)

Result objects are created by using the field names (or AS marked field names) wherever possible. If not possible (expression or something), the field will be named "_exp_N" where N goes from 1 on up as needed. Try to use reasonably AS clauses. it just makes it so much easier. expressions may not be supported at first.

Statements stick around until they are garbage collected.

File API

2009-01-21T00:01:27Z

129.42.161.36:

File is a built in class from SpiderMonkey, but its poorly documented. Going through the source code, it appears this is what we get for the interface.

Global properties of File:
*curdir (sp?):

Properties of File objects:
*length
*name
*parent
*size
...

Methods of File objects:
*new File([path])
*open()
*close()
*flush()
...

I've extended File to add an include and require:
*File.prototype.include(): Executes the contents of the File as a javascript script in place.
*File.prototype.require(): Executes the contents of the File as a javascript script in place, only if it has not already been executed as part of a require(). Keeps track by updating a property in the global File class object (required[])
*File.required[]: array of filenames that have already been executed by a require() call for the current script.
*File.prototype.execute(args array): Executes the File as with server.runCmd(File, args array) and returns the exit status

Server API

2009-01-21T00:00:20Z

129.42.161.36:

Data members on the global server object:
*env: array of environment variables, including standard request headers and server information

Functions on the global server object:
*logNotice(string|array of strings): function to log a notice (or a list of notices) to the server error log
*logError(string|array of strings): function to log an error (or a list of errors) to the server error log
*runCmd(cmdstring): function execute a command on the server (with the httpd daemon's permissions!) execution of the script will wait until the cmd is finished, and will return the exit status of the command.
*runCmd(cmd, array of args): same as above, but executes the given command with the arguments given in the array. arguments will be escaped or quoted as necessary
*runCmd(File, array of args): same as above, but takes the given command from the File object passed in.

ProcessConnection

2009-01-20T23:59:01Z

129.42.161.36:

ProcessConnection is a class to represent an external process running on the server that is started by this script and runs independently. It can be read and written to as well.

Start the process by creating a new ProcessConnection:
process = new ProcessConnection(cmd, args array)
process = new ProcessConnection(cmdandargs)
process = new ProcessConnection(File, args array)

Read and write just like for TCPConnections:
process.send(string | array of strings)
string = process.recvAll()
string = process.recvLine(chomp?)
array of strings = process.recvLines(numlines, chomp?)
bool = process.dataAvailable()

Closing the process can be done by garbage collection or explicit close():
status = process.close()

Note that close() blocks until the process ends and a status is returned. Garbage collection will do the same.

To send a signal to the process (and thus possibly killing it earlier, if needed):
process.signal(signum)

Exceptions can be thrown:
ProcessConnectionOpenError
ProcessConnectionChildClosed

TCPConnection

2009-01-20T23:57:17Z

129.42.161.36:

Wrapper for C socket API. Only works for now with IPv4 and TCP streams. Only client support for now as well. Just simpler.

Construct with:
connection = new TCPConnection(remotehost, remoteport)

Exceptions:
TCPConnectionError

Send and receive with:
connection.send(string | array of strings)
string = connection.recvAll()
string = connection.recvLine(chomp?)
array of strings = connection.recvLines(numLines, chomp?)
boolean = connection.dataAvailable()

Closure is done when garbage collected, or when close() is called directly:
connection.close()

ProcessConnection

2009-01-20T23:56:44Z

129.42.161.36: New page: ProcessConnection is a class to represent an external process running on the server that is started by this script and runs independently. It can be read and written to as well. Start th...

ProcessConnection is a class to represent an external process running on the server that is started by this script and runs independently. It can be read and written to as well.

Start the process by creating a new ProcessConnection:
process = new ProcessConnection(cmd, args array)
process = new ProcessConnection(cmdandargs)

Read and write just like for TCPConnections:
process.send(string | array of strings)
string = process.recvAll()
string = process.recvLine(chomp?)
array of strings = process.recvLines(numlines, chomp?)
bool = process.dataAvailable()

Closing the process can be done by garbage collection or explicit close():
status = process.close()

Note that close() blocks until the process ends and a status is returned. Garbage collection will do the same.

To send a signal to the process (and thus possibly killing it earlier, if needed):
process.signal(signum)

TCPConnection

2009-01-20T23:18:46Z

129.42.161.36: New page: Wrapper for C socket API. Only works for now with IPv4 and TCP streams. Only client support for now as well. Just simpler. Construct with: connection = new TCPConnection(remotehost, r...

Wrapper for C socket API. Only works for now with IPv4 and TCP streams. Only client support for now as well. Just simpler.

Construct with:
connection = new TCPConnection(remotehost, remoteport)

Exceptions:
TCPConnectionError

Send and receive with:
connection.send(string | array of strings)
string = connection.recvAll()
string = connection.recvLine(chomp?)
array of strings = connection.recvAllLines(chomp?)
boolean = connection.dataAvailable()

Closure is done when garbage collected, or when close() is called directly:
connection.close()

Modjs

2009-01-20T23:12:25Z

129.42.161.36:

[http://www.modjs.org modjs.org] has the rudiments of an apache module to handle server side javascript using SpiderMonkey.

SpiderMonkey [https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference APIs] and a [https://developer.mozilla.org/en/SpiderMonkey tutorial].
Apache Module [http://httpd.apache.org/dev/apidoc/ APIs] and a [http://httpd.apache.org/dev/API.html tutorial].

Would like [[MIME]] support, a global request/response object (both MIME trees I think), SQLite and MySQL support, and File IO Support (if its not already there). Also should have support for including other javascript sources. mod_js has an example for includes and some of the request/apache stuff. SpiderMonkey has an example shell that shows some support for File objects I think.

Would be nice to have libGD and/or ImageMagick support (EXIF too, if possible), as well as some sort of curl library to get to other sites to do stuff.

----
Things we should have:
*Class for MIME objects and MIME headers.
*Object with server info (environment, log functionality) [[server API]]
*Object with request info (request string (full and broken up), incoming mime object, maybe cookies already broken up, etc.) [[request API]]
*Object with response info (outgoing mime object, print functionality, obstack stuff, way to set headers, etc) [[response API]]
*File class extensions, if needed [[File API]]
*Better include support (add to File)
*MySQL/SQLite classes and support (new classes probably needed here)
*system call support (put this on server)
*image manipulation support (new classes probably needed here)
*json support (maybe just some quick functions on the response (encode) /request (decode) ? or maybe better as a global)
*curl support (new class probably, using MIME stuff to send and receive, probably wrapped by request/response like objects.. maybe they should be classes, too.)
*Instead of bothering with curl, maybe just have a way to open a socket and read/write to it for now.
*Classes: [[HTTPRequest API]], [[HTTPResponse API]], [[MailMessage API]], [[HTTPMessage API]], [[MimeEntity API]], [[MimeHeader API]]
*Classes: [[Socket API]], [[DbConnection API]], [[DbStatement API]]
*[[TCPConnection]]
*[[DbConnection]]
*[[ProcessConnection]]

Things the module should do if it can:
*Cache compiled javascript code?
*Stay alive? Might already do this...
*Cached javascript context? Would this make sense?
*Cached session stuff? Do I really want/need this?

MIME

2009-01-14T00:04:21Z

129.42.161.36:

Need to describe MIME headers and body types here, and what types of MIME bodies can be in multiparts/treed stuff, etc. This is really Entity, probably. Need to be able to distinguish between HTTP and MIME (mail) type entities. Also, an indicator as to whether the entity is currently encoded or decoded. Functions to encode/decode (to MIME transport spec, gzip, compress, etc). When the entity is encoded, it probably shouldn't be writable, if we can enforce that. Should have header access for raw header contents as well as an array of values, with true value, raw value group, and properties array for each value. Should have raw access to the body (including entity bodies, and multipart bodies), as well as split into the entity tree form. Preferably things are only added/changed/removed via the methods or non-raw arrays/hashes, and just viewed in the raw views.

HTTP-Message := HTTP-Request | HTTP-Response
MIME-Message := entity
HTTP-Request := request-line CRLF entity
HTTP-Response := status-line CRLF entity

entity := header-group CRLF entity-body
entity-body := text-body | entity | multipart-group
multipart-group := leader (CRLF boundary CRLF entity)+ CRLF boundary-end CRLF trailer

text-body := <true entity content>
leader := <content that is not important and must be discarded when encountered>
trailer := <content that is not important and must be discarded when encountered>

header-group := header*
header := header-name ':' header-value CRLF
header-value := values
values := (value-exp ',')* value-exp
value-exp := real-value (';' property-exp)*
real-value := value-key ['=' value-value]
property-exp := property-key ['=' property-value]

*Header comments are in '(' ')' and should not be kept except in the raw header value.
*Header contents can have double quoted strings for atoms.
*Line folding can happen (header line followed by CRLF LWSP extra line), but should be decoded as soon as possible by the entity (right after receiving the mail message), and encoded only at the last moment (before sending the mail message). HTTP headers don't need line folding.
*Be careful with cookies (usually will have a cookie header that appears as one value with all other values being properties of that value, which is incorrect, they are usually all distinct values. However, value-keys that start with '$' are usually actually properties of the preceding value, and so that's why we have to store all "properties" as an array, not a hash, since we could have duplicate names, and order matters in that regard. The HTTP-Request class should properly interpret cookies and store them as a hash at that level, with properties appropriately split out. That is where they should be accessed. Similarly, new cookies should be added in the HTTP-Response level cookie jar, where they can be correctly remerged into the proper header format at send time. Probably both request and response should have a linked cookie jar with better abstraction to properly handle cookie deletion, new cookies, etc., while making cookie actions more transparent to the user (simple access should be possible, while simultaneously encoding and decoding access).
*Keep in mind that by and large only the top level entity headers "matter" for the given message type. Deeper entity headers really don't matter much, except to decode/encode their containing bodies, as with all abstract entities. For example, Cookie headers deep in multipart entities of request messages aren't parsed into the request cookie jar. Similarly, transport limitations of mail messages are enforced at the top level entity, and hopefully any lower level entities get encoded before insertion into the message if they need newline preservation or line length preservation contrary to mail specifications.
*Request messages will break up the request string, query string, post data, cookie data, etc., as needed.
*Response messages have to ensure the proper apache request_rec values get set based on header data in the response and the status information, and determining which cookies need to get set. They also need the obstack support for printing, etc.
*Mail messages have lots to do in terms of encoding and decoding messages for transport, header folding, newline handling, etc. at send and receive time.

MIME

2009-01-13T22:53:23Z

129.42.161.36:

Need to describe MIME headers and body types here, and what types of MIME bodies can be in multiparts/treed stuff, etc. This is really Entity, probably. Need to be able to distinguish between HTTP and MIME (mail) type entities. Also, an indicator as to whether the entity is currently encoded or decoded. Functions to encode/decode (to MIME transport spec, gzip, compress, etc). When the entity is encoded, it probably shouldn't be writable, if we can enforce that. Should have header access for raw header contents as well as an array of values, with true value, raw value group, and properties array for each value. Should have raw access to the body (including entity bodies, and multipart bodies), as well as split into the entity tree form. Preferably things are only added/changed/removed via the methods or non-raw arrays/hashes, and just viewed in the raw views.

HTTP-Message := HTTP-Request | HTTP-Response
MIME-Message := entity
HTTP-Request := request-line CRLF entity
HTTP-Response := status-line CRLF entity

entity := header-group CRLF entity-body
entity-body := text-body | entity | multipart-group
multipart-group := leader (CRLF boundary entity)+ boundary-end trailer

text-body := <true entity content>
leader := <content that is not important and must be discarded when encountered>
trailer := <content that is not important and must be discarded when encountered>

header-group := header*
header := header-name ':' header-value CRLF
header-value := values
values := (value-exp ',')* value-exp
value-exp := real-value (';' property-exp)*
real-value := value-key ['=' value-value]
property-exp := property-key ['=' property-value]

*Header comments are in '(' ')' and should not be kept except in the raw header value.
*Header contents can have double quoted strings for atoms.
*Line folding can happen (header line followed by CRLF LWSP extra line), but should be decoded as soon as possible by the entity (right after receiving the mail message), and encoded only at the last moment (before sending the mail message). HTTP headers don't need line folding.
*Be careful with cookies (usually will have a cookie header that appears as one value with all other values being properties of that value, which is incorrect, they are usually all distinct values. However, value-keys that start with '$' are usually actually properties of the preceding value, and so that's why we have to store all "properties" as an array, not a hash, since we could have duplicate names, and order matters in that regard. The HTTP-Request class should properly interpret cookies and store them as a hash at that level, with properties appropriately split out. That is where they should be accessed. Similarly, new cookies should be added in the HTTP-Response level cookie jar, where they can be correctly remerged into the proper header format at send time. Probably both request and response should have a linked cookie jar with better abstraction to properly handle cookie deletion, new cookies, etc., while making cookie actions more transparent to the user (simple access should be possible, while simultaneously encoding and decoding access).
*Keep in mind that by and large only the top level entity headers "matter" for the given message type. Deeper entity headers really don't matter much, except to decode/encode their containing bodies, as with all abstract entities. For example, Cookie headers deep in multipart entities of request messages aren't parsed into the request cookie jar. Similarly, transport limitations of mail messages are enforced at the top level entity, and hopefully any lower level entities get encoded before insertion into the message if they need newline preservation or line length preservation contrary to mail specifications.
*Request messages will break up the request string, query string, post data, cookie data, etc., as needed.
*Response messages have to ensure the proper apache request_rec values get set based on header data in the response and the status information, and determining which cookies need to get set. They also need the obstack support for printing, etc.
*Mail messages have lots to do in terms of encoding and decoding messages for transport, header folding, newline handling, etc. at send and receive time.

MIME

2009-01-13T22:32:11Z

129.42.161.36:

MIME

2009-01-13T18:01:41Z

129.42.161.36:

MIME

2009-01-09T23:51:50Z

129.42.161.36: New page: Need to describe MIME headers and body types here, and what types of MIME bodies can be in multiparts/treed stuff, etc.

Need to describe MIME headers and body types here, and what types of MIME bodies can be in multiparts/treed stuff, etc.

Modjs

2009-01-09T23:51:14Z

129.42.161.36:

[http://www.modjs.org modjs.org] has the rudiments of an apache module to handle server side javascript using SpiderMonkey.

SpiderMonkey [https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference APIs] and a [https://developer.mozilla.org/en/SpiderMonkey tutorial].
Apache Module [http://httpd.apache.org/dev/apidoc/ APIs] and a [http://httpd.apache.org/dev/API.html tutorial].

Would like [[MIME]] support, a global request/response object (both MIME trees I think), SQLite and MySQL support, and File IO Support (if its not already there). Also should have support for including other javascript sources. mod_js has an example for includes and some of the request/apache stuff. SpiderMonkey has an example shell that shows some support for File objects I think.

Would be nice to have libGD and/or ImageMagick support (EXIF too, if possible), as well as some sort of curl library to get to other sites to do stuff.

----
Things we should have:
*Class for MIME objects and MIME headers. [[MimeObject API]] [[MimeHeader API]]
*Object with server info (environment, log functionality) [[server API]]
*Object with request info (request string (full and broken up), incoming mime object, maybe cookies already broken up, etc.) [[request API]]
*Object with response info (outgoing mime object, print functionality, obstack stuff, way to set headers, etc) [[response API]]
*File class extensions, if needed [[File API]]
*Better include support (add to File)
*MySQL/SQLite classes and support (new classes probably needed here)
*system call support (put this on server)
*image manipulation support (new classes probably needed here)
*json support (maybe just some quick functions on the response (encode) /request (decode) ? or maybe better as a global)
*curl support (new class probably, using MIME stuff to send and receive, probably wrapped by request/response like objects.. maybe they should be classes, too.)

Things the module should do if it can:
*Cache compiled javascript code?
*Stay alive? Might already do this...
*Cached javascript context? Would this make sense?
*Cached session stuff? Do I really want/need this?

File API

2009-01-09T20:03:00Z

129.42.161.36: New page: File is a built in class from SpiderMonkey, but its poorly documented. Going through the source code, it appears this is what we get for the interface. Global properties of File: *curdir...

File is a built in class from SpiderMonkey, but its poorly documented. Going through the source code, it appears this is what we get for the interface.

Global properties of File:
*curdir (sp?):

Properties of File objects:
*length
*name
*parent
*size
...

Methods of File objects:
*new File([path])
*open()
*close()
*flush()
...

I've extended File to add an include and require:
*File.prototype.include(): Executes the contents of the File as a javascript script in place.
*File.prototype.require(): Executes the contents of the File as a javascript script in place, only if it has not already been executed as part of a require(). Keeps track by updating a property in the global File class object (required[])
*File.required[]: array of filenames that have already been executed by a require() call for the current script.

Server API

2009-01-09T19:56:47Z

129.42.161.36:

Server API

2009-01-09T19:55:47Z

129.42.161.36: New page: Data members on the global server object: *env: array of environment variables, including standard request headers and server information Functions on the global server object: *logNotice...

Data members on the global server object:
*env: array of environment variables, including standard request headers and server information

Functions on the global server object:
*logNotice(string|array of strings): function to log a notice (or a list of notices) to the server error log
*logError(string|array of strings): function to log an error (or a list of errors) to the server error log
*system(cmdstring): function execute a command on the server (with the httpd daemon's permissions!) execution of the script will wait until the cmd is finished, and will return the exit status of the command.
*system(cmd, array of args): same as above, but executes the given command with the arguments given in the array. arguments will be escaped or quoted as necessary

Modjs

2009-01-09T19:44:11Z

129.42.161.36:

[http://www.modjs.org modjs.org] has the rudiments of an apache module to handle server side javascript using SpiderMonkey.

SpiderMonkey [https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference APIs] and a [https://developer.mozilla.org/en/SpiderMonkey tutorial].
Apache Module [http://httpd.apache.org/dev/apidoc/ APIs] and a [http://httpd.apache.org/dev/API.html tutorial].

Would like MIME support, a global request/response object (both MIME trees I think), SQLite and MySQL support, and File IO Support (if its not already there). Also should have support for including other javascript sources. mod_js has an example for includes and some of the request/apache stuff. SpiderMonkey has an example shell that shows some support for File objects I think.

Would be nice to have libGD and/or ImageMagick support (EXIF too, if possible), as well as some sort of curl library to get to other sites to do stuff.

----
Things we should have:
*Class for MIME objects and MIME headers. [[MimeObject API]] [[MimeHeader API]]
*Object with server info (environment, log functionality) [[server API]]
*Object with request info (request string (full and broken up), incoming mime object, maybe cookies already broken up, etc.) [[request API]]
*Object with response info (outgoing mime object, print functionality, obstack stuff, way to set headers, etc) [[response API]]
*File class extensions, if needed [[File API]]
*Better include support (add to File)
*MySQL/SQLite classes and support (new classes probably needed here)
*system call support (put this on server)
*image manipulation support (new classes probably needed here)
*json support (maybe just some quick functions on the response (encode) /request (decode) ? or maybe better as a global)
*curl support (new class probably, using MIME stuff to send and receive, probably wrapped by request/response like objects.. maybe they should be classes, too.)

Things the module should do if it can:
*Cache compiled javascript code?
*Stay alive? Might already do this...
*Cached javascript context? Would this make sense?
*Cached session stuff? Do I really want/need this?

Modjs

2009-01-09T19:42:37Z

129.42.161.36:

[http://www.modjs.org modjs.org] has the rudiments of an apache module to handle server side javascript using SpiderMonkey.

SpiderMonkey [https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference APIs] and a [https://developer.mozilla.org/en/SpiderMonkey tutorial].
Apache Module [http://httpd.apache.org/dev/apidoc/ APIs] and a [http://httpd.apache.org/dev/API.html tutorial].

Would like MIME support, a global request/response object (both MIME trees I think), SQLite and MySQL support, and File IO Support (if its not already there). Also should have support for including other javascript sources. mod_js has an example for includes and some of the request/apache stuff. SpiderMonkey has an example shell that shows some support for File objects I think.

Would be nice to have libGD and/or ImageMagick support (EXIF too, if possible), as well as some sort of curl library to get to other sites to do stuff.

----
Things we should have:
*Class for MIME objects and MIME headers. [MimeObject API] [MimeHeader API]
*Object with server info (environment, log functionality) [server API]
*Object with request info (request string (full and broken up), incoming mime object, maybe cookies already broken up, etc.) [request API]
*Object with response info (outgoing mime object, print functionality, obstack stuff, way to set headers, etc) [response API]
*File class extensions, if needed [File API]
*Better include support (add to File)
*MySQL/SQLite classes and support (new classes probably needed here)
*system call support (put this on server)
*image manipulation support (new classes probably needed here)
*json support (maybe just some quick functions on the response/request ? or maybe better as a global)
*curl support (new class probably, using MIME stuff to send and receive)

Things the module should do if it can:
*Cache compiled javascript code?
*Stay alive? Might already do this...
*Cached javascript context? Would this make sense?
*Cached session stuff? Do I really want/need this?

Modjs

2009-01-07T19:39:59Z

129.42.161.36:

Thoughts on PWM

2008-10-16T16:23:26Z

129.42.161.36:

So, we turn off outputting automatically, set up interrupts on mid and top. Set the period to something reasonable, and the resolution to something largish.

There should be a table in RAM, of duty cycles for each chosen output pin. Should be single (double) byte entries for each pin specifying the fraction of 255 slots that should be ON for that pin. Each entry should contain:
*(byte): next entry in sorted sequence (in entry numbers, so *4 is the offset from start. FF indicates end of list)
*(byte): output port for this entry (upper nibble determines which set of 8 pins (PAx=0,PBx=1,PCx=2,PDx=3,PEx=4,PFx=5...), lower nibble determines which pin of the 8 to use)
*(word): duty cycle specification (might just be one byte, with a one byte pad)

Before the table should be a dummy entry, stating which entry to start with, how many entries there are, and what the resolution is (maybe?)

When the top interrupt fires, we turn on outputs to all pins, then navigate our sorted table by jumping through the next thingies to find the first pin that will need to be shut off. We place that pin's duty cycle value in mid, and return.

When mid fires, we work through our sorted table, turning off all pins until we find a value that exceeds our current mid. Then we change mid to that new value, and return.

When adding a new entry to the table, turn off interrupts (or at least the top and mid ones), update the total number of entries, place a new entry at the end of the table, then figure out where in the sequence it belongs, and reshuffle next ptrs to include the new entry. Then turn back on interrupts. We may have missed one of them, but it should fire at that point, I think?

When removing an entry, turn off interrupts (or at least top and mid), find the old entry for this port, and copy the last entry in the table to that slot. Have to reshuffle next ptrs for the one that used to point at the deleted entry, and the one that used to point at the last entry. Then we update the total number of entries, turn off the output to the port, and turn back on interrupts.

Note that to change the duty cycle of a port, it has to be removed and readded. No need to turn off ints in between the two operations, I don't think.

Thoughts on PWM

2008-10-16T16:23:08Z

129.42.161.36: New page: So, we turn off outputting automatically, set up interrupts on mid and top. Set the period to something reasonable, and the resolution to something largish. There should be a table in RA...

So, we turn off outputting automatically, set up interrupts on mid and top. Set the period to something reasonable, and the resolution to something largish.

There should be a table in RAM, of duty cycles for each chosen output pin. Should be single (double) byte entries for each pin specifying the fraction of 255 slots that should be ON for that pin. Each entry should contain:
(byte): next entry in sorted sequence (in entry numbers, so *4 is the offset from start. FF indicates end of list)
(byte): output port for this entry (upper nibble determines which set of 8 pins (PAx=0,PBx=1,PCx=2,PDx=3,PEx=4,PFx=5...), lower nibble determines which pin of the 8 to use)
(word): duty cycle specification (might just be one byte, with a one byte pad)

Before the table should be a dummy entry, stating which entry to start with, how many entries there are, and what the resolution is (maybe?)

When the top interrupt fires, we turn on outputs to all pins, then navigate our sorted table by jumping through the next thingies to find the first pin that will need to be shut off. We place that pin's duty cycle value in mid, and return.

When mid fires, we work through our sorted table, turning off all pins until we find a value that exceeds our current mid. Then we change mid to that new value, and return.

When adding a new entry to the table, turn off interrupts (or at least the top and mid ones), update the total number of entries, place a new entry at the end of the table, then figure out where in the sequence it belongs, and reshuffle next ptrs to include the new entry. Then turn back on interrupts. We may have missed one of them, but it should fire at that point, I think?

When removing an entry, turn off interrupts (or at least top and mid), find the old entry for this port, and copy the last entry in the table to that slot. Have to reshuffle next ptrs for the one that used to point at the deleted entry, and the one that used to point at the last entry. Then we update the total number of entries, turn off the output to the port, and turn back on interrupts.

Note that to change the duty cycle of a port, it has to be removed and readded. No need to turn off ints in between the two operations, I don't think.

Some avr stuff

2008-10-16T16:06:22Z

129.42.161.36: New page: *thoughts on PWM

*[[thoughts on PWM]]