Musical Dice in Acorn User
Alan Minns
If any members receive the Acorn User monthly disc and have
tried (without success) to load Ian Waugh's program, the following may be
useful.
For some strange reason, the end of each line is terminated with
a line feed instead of a carriage return. As far as AMPLE is concerned, this
means that the whole program is one very long line.
The solution is to run a BASIC program such as:
10 *LOAD Music 3000
20 FOR I%=0 TO &21AA
30 IF I%?&3000=&A I%?&3000=&D
40 NEXT
50 *SAVE C.Music 3000+21AB
60 END
20 FOR I%=0 TO &21AA
30 IF I%?&3000=&A I%?&3000=&D
40 NEXT
50 *SAVE C.Music 3000+21AB
60 END
Then, in AMPLE,
*EXEC C.Music
and all should be well.
Making audio copies of AMPLE music
Lol Taylor
Those who have the Master may find the following time check
method a help. When planning an audio tape it will be useful to know the exact
length of each piece. Then all the necessary files can be entered in a jukebox ready
for the recording session. Allow about 12 seconds for jukebox and loading time
between each piece when calculating what pieces will fit on to the available
tape.
In the *EXEC file which I load in when beginning a new piece
are the following words:
"time" [ "TIME" OSCLI ]
"endtime" [
REP( QTIME 0 #< )UNTIL( IDLE )REP
time ]
REP( QTIME 0 #< )UNTIL( IDLE )REP
time ]
"part1z" [endtime]
"tab" [ #IN #2 ]
Once I am satisfied with a piece I call up the RUN word in
Notepad and enter 'time' immediately before the PLAY instruction. In the PLAY instruction
I add part 'z', and after the PLAY instruction 'tab'. Running the program from
the MENU the internal clock times come up on the screen. Taking one from the
other I calculate the length of the piece, and enter it into my (hand-written)
piece register. After that I remove the above words from the RUN word and
delete them.
If the timing words are left in the RUN word and the piece
is run from the Mixing Desk, some queer messages appear. They don't harm the
program however.
Unfortunately, if you do not have a Master this method is
not much help, but someone who understands the internal clocks may be able to
work something out for the BBC Model B.
Clearing public data
Tony Walduck
With the Hybrid AMPLE Toolbox, it is possible for programs
to have associated public data:
TXT data from TEDIT
TEL data from IEDIT
LNT data from LEDIT (in UTILS)
TEL data from IEDIT
LNT data from LEDIT (in UTILS)
This is stored with the program (taking space on the disc)
and will cause loaded programs to be larger than necessary.
At one point I had accumulated some TXT data in a program,
which I wished to get rid of, but through not understanding the concept of
public data, I could not reliably get rid of it.
It was only after reading the Toolbox manual (always the
best idea!) that I learnt that as the Main Menu editors do not use public data,
their CLEAR commands only work on the data of that particular editor alone.
It is only when you are using a public data editor (any
one), or in no editor (e.g. in Main Menu) that the CLEAR command will actually
act on public data.
QUIT will also remove public data, but NEW has no effect on
it.
Beware: just entering TEDIT (with nothing visible in the
editor) will generate 5 bytes, whilst going into IEDIT will immediately
generate 1020 bytes of blank data!
Why you should not modify C.PREPARE
Alan Minns
In AMPLINEX 019, Tony Walduck refers to earlier hints on
changes to the C.PREPARE routine and David Bloxham mentions the memory gain achieved
by deleting the S parameter.
C.PREPARE appears in the !BOOT file and is called with the
parameters R, S and K (the order is unimportant). If present, they perform the
following functions:
R - checks if OSHWM=&1900. If so, it changes the value to
&1300 otherwise does nothing
S - explodes the font and defines the special set of characters
for the Staff editor (*)
K - defines the function key strings.
* Since the defined characters occupy 2 pages of memory in
addition to page &C, this explains the gain in memory of 1/2K.
It was in AMPLINEX 010 that Allan Gardner suggested
alterations to C.PREPARE, although he was not the first to do so. I maintain
that this is never necessary!
OSBYTE 179 allows one to read/write the value of OSHWM
(Allan refers to this as PAGE which, as a BASIC function, has no meaning
outside that environment). For example, *FX179,20 will set OSHWM to &1400
(remember that FX parameters are in decimal) - it can thus be used when the R
parameter in C.PREPARE has no effect.
If an Aries board is fitted, the link should be set so that
Shadow is not initiated at switch on. The start of the !BOOT file may then be
rewritten:
*BASIC
*XON 20 13
MODE 7
*FX179,20
*/C.PREPARE S K
... etc.
*XON 20 13
MODE 7
*FX179,20
*/C.PREPARE S K
... etc.
Surely this is easier than modifying C.PREPARE itself?
A further point concerns the inclusion of the MODE 7
command. Since Shadow is specified with static (as opposed to dynamic)
workspace, a Break is not necessary and the mode change suffices.
There is also an unofficial method of changing the workspace
page for Aries but this involves knowledge of the slot occupied by the Aries
ROM - if anyone is interested, please contact me via AMPLINEX.
Tape recorder speed
Lol Taylor
Since programming pieces using the Music 5000 I have at
times given audio cassette copies to relations and friends. I received
criticisms that my pieces were too fast.
So I recently programmed a measured 5 minutes. I used a
speed of 100 ticks per minute, and had instruments beep at different regular
intervals, playing a chord together at end of each minute. Before this chord
were five lead-in beeps to help with stopwatch synchronisation.
Using the stopwatch I checked that the computer was spot-on.
Then I recorded my piece on various tape decks and played them back on others.
I found a deviation of over 3% slow on my 'best' tape deck! This was getting on
for a semitone sharp, apart from the racing effect, when my pieces were played back
on other machines.
Published in AMPLINEX 020, November
1990
