Re: [cc65] abc music specification

On Wednesday 22 December 2004 10:51, Karri Kaksonen wrote:

> Wrong. There is several decent editors already. I have a few thousand
> tunes in this format already that I downloaded from the net. And there is
> conversion programs freely available to convert form midi and other
> formats.

well i wasnt talking about the ABC format, but about any format in general. so
assuming that format isnt perfect for us, we'd need to create an editor :)

but indeed you've just mentioned a big plus of generic formats in general -
there are usually editors for them widely available :)
 
> Plus it is not bulky, slow or anything related to that. My version for the
> Lynx using 4 simultaneous channels as taken from my map-file is:
> 
> abcmusic.o:
>     CODE              Offs = 000A0D   Size = 00046D
>     RODATA            Offs = 00002C   Size = 00003D
>     DATA              Offs = 00006D   Size = 00003E
> 
> And this is lousy code as I am a lousy assembler coder.
> 
> In the hands of a capable coder it could probably drop in half.

ok that doesnt look _that_ bad. to come up with some figures, the "common" c64
tune takes about 0x1000 bytes for the player AND all music data. on the vic20, 
you'd want less than that, maybe not more than 0x800 or so. so how memory intense
are those tunes commonly?

and as for speed, "modern" c64 player typically run at about $18 rasterlines per frame,
which means 63*$18=1512 cycles per player call. can you give a simelar figure for yours?

> > imho this needs to be discussed a lot, needs comments from the atari and apple ppl
> 
> Hard to argue with this comment...

*G*

i think this is very important. every target has its own unique sound hardware, restrictions
and whatnot. imho it wouldnt be very wise to start without having heard opinions and suggestions
from all directions. so speak up ppl! :)

> > tjam, a thing that would be entire possible, and much easier to define and implement would
> > be a driver to play samples though...maybe we should start with that. (i might be able to
> > contribute a modded version of SAM *cough* :=P)
> 
> This is a different thing that is also needed. The Lynx hardware can be
> set up
> 1) to support samples be giving access to a D/A circuit directly
> 2) or to control oscillators and shift registers for producing the sound.
> 
> I feel that samples should provide a different set of drivers to do the job.
> The alternative 1 costs CPU-time while alternative 2 is virtually free. So
> for calculation intensive games I prefer alternative 2.

yes thats probably the same on all targets. samples are rarely used, most of the times
 for occasional sound fx or additional voices in a title-screen tune (where cpu doesnt
matter). samples also take a relativly huge amount of ram on most targets so using
them is rather the exception than the rule.
 
> So I vote for keeping a music player driver separate from a sample player.
> And I would also like to see both drivers available on the cc65 compiler.

agreed :)

however if we keep the sample player seperate, another idea (i'm not sure if good
or not) would be to keep a "chip voice" driver seperate aswell. that one would
be capable to just play a single note on the soundchip. then the musicplayer
itself could be in a third module, which in turn could use the chip-driver,
the sample-player, or both.

oh, and we shouldnt forget about sound effects. ie the driver should provide funtions
to play predefined sounds independently from each other, and with- or without the
music playing at the same time.

gpz
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.