Subject: Re: Iseq music composition program released
Newsgroups: comp.sys.cbm,alt.c64

Hola Agemixer :)

In article <[email-masked]>,
Agemixer  <[email-masked]> wrote:
>
>On 10 Jun 2002, Steve Judd wrote:
>
>Referring to the docs, it seems to be missing atleast some flexible
>wavelist/arpeggio, and seems to be replaced with 'fixf' feature. For
>example, how could i do a continuous bass sound sequence like this can
>be done in Iseq:?
>
>Wave  trp+
> 51    0c
> 41    0c
> 41    0c
> 41(0) 00
> 41(0) 00
> 41(0) 00
> 41(0) 00
> 40    00
> 40    00
> 40    00

Well, I'm not sure what the trp+ is, but I assume the "Wave" settings are
$d404 settings.  In Iseq, I'd just create a sequence of length 8 and enter
those values (although I wouldn't use $51 :) -- when I used mixed waveforms
in the past they didn't work on lots of SIDs).

Instead of a program with a set of built-in features, I've had this sort-of
vision of a flexible set of tools that let you manipulate SID and compose
music -- a "shell" with a set of musical building blocks that you could define
and combine into anything you wanted, that let you control exactly what happens
and give you total control over SID and the player's behavior (not a
programming language; just a set of tools and a framework).  That motivated
a lot of Iseq.

Any music player can only write to SID every time it's called.  In iseq, you
specify exactly what gets written on each call.  If you want to modify the
frequency register, you do it; same for the filters, ASDR, waveforms, etc.;
all registers are available to each instrument.  The goal is to give you
full control over what gets written to SID.

In addition to plain sequences -- which can be written continuously or
just once -- there are also "modulators", for example ramps, which can go
from A to B step C, and adders, which can add sequences of values.

The "fixf" thingie is something different.  fixf just restores the frequency
after a little bit -- for example, the bass+hihat example instrument sets the
waveform to noise, then triangle, then pulse; meanwhile, the frequency
needs to be high for the first two player calls, then restored to its
original frequency.  That is:

1st player call:  waveform=$81  freq=$a000 (or whatever)
2nd player call:  waveform=$11  freq=$a000
3rd player call:  waveform=$41  freq=original value

fixf restores the frequency, that's all.

All of these are meant to be tools, for manipulating SID.  They are
actually compiled into the player during editing, and this makes it very
easy to add more.  Anything you want, to manipulate SID, can potentially
be added in.

Arpeggios are in there -- ctrl-a from the instrument editor brings up
the arpeggio editor.  Arpeggios can be any length and speed, can have
positive and negative offsets, and can either run continuously or one-shot.

>And an another issue, i didn't find a single word of "slide", "glide",
>"tie", or even "vibrato" effects from the docs, so i guess they are
>completely missing. Actually those are very important for the quality of
>the tune sounds and enjoyability... though most of those aren't
>made too well in some very known editors around, i had to replace the
>glitching glide sounds with my own methods with wavelists + ties, and even
>vibratos if the editor just made it possible.

Well, like a lot of things I probably was dumb and didn't mention it in the
docs, but part of the Iseq philosophy of "you control the SID" is that it
doesn't have built-in effects.  Instead, it tries to provide the tools
you need to build your own effects.  It tries to not limit you to whatever
effect is built into the player.

So, for example, the instrument editor has a thingie called "frq+".  With
frq+, values are added to the current frequency.  So if you want a vibrato,
you enter a set of frq+ values to increase and decrease the frequency,
and loop it continuously:

frq+  0100 0200 0100 0000 ff00 fe00 ff00 0000

On the downside, it's not "proportional" -- you wouldn't use the same
modulations at low and high frequencies.  On the plus side, you get to
specify exactly what you want, and combine it with stuff to make more
complex effects; for example, it's easy to, say, combine a vibrato with a
rising frequency, or make little ornaments for notes, or an 'asymmetric'
vibrato -- anything you can think of.

This is also the idea for slides and glides -- again, the idea was that
they're not built in, but the tools are there to make them.  They can also
be done using the arpeggio editor.  Since this is kind-of a crappy way of
implementing them, philosophical purity of not having any built-in fx may
be abandoned in a future release :).  But from your descriptions above, it
sounds like building your own slides was necessary anyways.  So the question
is: is there a _better_ way of implementing slides, a way which lets you,
the composer, control exactly what happens?  I couldn't think of one, but
I'm very open to ideas.

Ties are built into the player.  Players typically do things automatically
for the composer -- restart instruments, toggle gates, etc.  With the aim
of giving control to the composer, Iseq has switches for all those things.
You can turn gate toggling on/off, restarts on/off, and so on.  There are
also two special notes, "hold" (continue previous note) and "rest" (zero
frequency).  One way to do a tie is to turn off instrument restarts and
hold the note; another way is to just define a longer duration!  Slurs
and such are similar -- just turn off the parts that reset instruments.

It makes the player a little bulkier and less efficient, but again, I don't
want the player to automatically assume what you want and do stuff for you --
I want you to have the abilitiy to control the behavior exactly.

>...
>more common method that F1/F3/F5/F7 = play/stop/cont/f.forward
>(DMC-styled) or something similiar. The idea is to get rid of multiple
>keypresses for most common keypresses. But it is also a good idea to hide
>f.e. clear track, clear instruments undo commands and things like this,
>behind any press-together of either SHIFT, CBM or CTRL. For example, Home
>...
>And why not implementing different keysets (DMC-like, JCH-like) to improve
>one's get-in-touch. Atleast I planned that for my tracker project years
>ago.

Good idea.  Thanks for the suggestions/tips; I'll keep them in mind!

I tried to make common keypresses single-key -- notes, durations, etc. --
and group other functions together under the ctrl-keys.  I just couldn't
stomach using something like "m" and "n" for "turn gate toggle off/on".
I think I would have ran out of keys anyways.

>I remember the Voicetracker times, when you HAD to type the whole
>C#4.1f command to get the note and a duration for it. Argh! :)

Yeah, that's what happened in my first player(s) (blahtune/tunesmith).  It's
not horrible, but it sure gets old fast.  I think Iseq does a reasonable job
of getting around this -- just changing durations when necessary -- but
kind-of like a tracker I'm concerned that it gets me thinking about the
composition in rigid intervals, i.e. every note becomes a 4/4 kind of note.
(If that makes any sense :).

>> >With first tests it hungs when adjusting the speed
>>
>> I'm sorry, could you be more specific?  (If there's a bug, I'll need more
>> information).
>
>When you press cbm +/- some times (during playing) it reserves a lot of
>rastertime and plays the tune in a high speed, but pressing any keys
>has no effect.

Hmmm.  cbm+ doubles the playback speed, while cbm- halves it.  If cbm+ is
pressed too many times things will get out of control -- IRQs start happening
faster than they can be acknowledged.  But keys should still work.  I'll
have a look (and try to break it).

>> >and the loader doesn't seem to work with Action Replay cartridge.
>>
>> This is a strange thing, and the fault of AR.  The "loader" is just the kernal
>> LOAD routine -- totally standard.  For some reason AR seems to get confused,
>> maybe when the call to LOAD is done from bank 2.
>
>Ok. (It may be an emulator bug too, sorry.)

No, it's an AR thing, and you're absolutely right.  I was stupid to not
have a fix in place, since everyone and their brother uses AR.  Programs that
don't work with AR are programs that don't get run!

>> Using the CIA timers _removes_ restrictions.
>
>It _does_ the restrictions, if one made a tune with CIA timing, and i
>need to use it with a fullscreen FLI demo or raster timing stuff :)

Well, this is another place where I was stupid and left some important
information out of the manual.  Here's what I should have said: just set
the first tempo value to $4cc7 (using ctrl-t) and it will behave just like
a VIC interrupt.

$4cc7 is the PAL setting; $42c6 is the normal NTSC setting, and $417f is
for old NTSC R56A VICs (64 cycles per line).

Also, when you clear a tune using shift-clear, the code checks whether the
machine is PAL or NTSC and _should_ set the value appropriately -- another
thing left out of the docs.  Bleah.

Anyways, the bottom line is that you can make it work just like a normal VIC
interrupt -- you're just not limited to a VIC interrupt.

>Hmm, a so-called 100% cover of Commando tune by Rob Hubbard could do
>fine :)
>
>/hvsc/hvsids-4.6/Hubbard_Rob/Commando.sid
>/hvsc/hvsids-4.6/VARIOUS/A-F/Agemixer/Commando_Remix.sid
>
>which i covered with DMC 4.0B, this editor is easy but one of
>hardest ones for covering anything well. :)

Heh, cool.  OK, I'll take you up on it :).  But you'll have to describe the
instruments to me -- I'm pretty clueless as to duplicating instruments I
haven't done before.  (We can do this in email).

That is, if this is a test of my abilities -- well, I lose, I can do the notes
from memory but I don't know how to make his instruments.  But if it's a test
of iseq's abilities, well, some information would be most helpful :).

>Most of the judgement is based on first experience and feeling.
>But now you know atleast one who even bothered to test the editor =)

Yep, fair enough, and I would surely have a similar reaction, if not worse;
if I can't figure something out quickly I usually put the program aside,
and I should have put more work into easing into this one.  Oh well.

As to the second, what makes it REALLY rare is that you not only tried
the program, but made COMMENTS on it! :)  (That _never_ happens!)

>Those horizontally placed notes in sequences in iseq is very strange for
>music. Not that the common oldie note and delay staves with G-key are
>also... :)

Well, that's a funny thing.  We read books left to right, and sheet music
left to right.  There's more columns than rows on the screen, too.  So I
began to wonder why 64 tunes are written like Chinese script.

One reason is of course that if the information is "wide", more of it fits
in columns.  And I learned another reason -- vertical stacking is a lot
easier to code than horizontal (especially with variable-width fields)!  But
Iseq fits, what, 12 "tracks" on the screen at a time by using rows, and more
notes are visible at a time.  You can see at a glance which are used, which
are left, which parts go where.  It's taken me some getting used to, too,
but, well, I actually like it!

>It is also missing the on-screen octave information, that is important to
>see the current playing note octave.

Well.... this is another one that got to bugging me.  Tunesmith displays
note, octave, and duration on the screen, and I realized that I never
found the octave/duration information useful, but instead spent all my
time single-stepping to find my place in the tune.  Iseq displays the
current octave at the top of the screen, and displays the octave in the
"long" description of the note under the cursor.  I did try putting the
octave information in with the note, but decided that

	A B C# B C# A D

was a lot cleaner looking than

	A-4 B-4 C#-4 B-4 C#-4 oops ran out of screen room

so it went into the long description instead (at the bottom of the screen).

>A some kind of sequence position is necessary for editing, too.

Hey, great idea :).

>I know the feeling, there is a lot of 'unfinished' editors around that
>either weren't flexible enough, or, the music routines took a lot of
>rastertime... So i decided to start my own tracker project, meanwhile a
>lot of people wanted to kill my project "aren't there already enough of
>good trackers around yet", "This will become nothing anyway, everybody
>already uses their own music players", "This kind of editor is already
>being under construction, see this link blahblah.." and mumblings like
>that.

Bah.  That's Bull.  I totally think you should write your own player.  As
you say, current programs do _not_ do everything they can or should do.
Besides, you're an experienced and high quality composer, so why should you
have to depend on others for your composition needs, especially when those
needs aren't being met?

Now, if it means you'll have to stop composing for a while and/or get
bogged down in a bunch of coding, well, forget it -- talk some coder info
adding the features you want :).  Or maybe someone has released some source
code that can be modified.   Otherwise, there's always room for more,
new programs.  That's what keeps the C= going, and if it makes you a more
productive composer then where's the problem?

(I almost hate to mention it, but you can always tell ME what features
you'd like to see :).

Anyways, I really do appreciate the comments, and the chance to defend
poor little iseq (actually, it's something like 70 blocks of code -- not
tables, graphics, music, and code; just code -- which is really humongous).

Further comments, good or bad, are unexpected but always welcome :).  I
rarely read comp.sys.cbm though, so maybe email is better.

And Agemixer: get busy on the Ultimate Tracker! :)

cu,

-Steve