octal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: big picture stuff (was re: widget)


From: David O'Toole
Subject: Re: big picture stuff (was re: widget)
Date: Fri Feb 2 17:54:02 2001

On Fri, 2 Feb 2001, Matthew Itkin wrote:

>This is a great idea for making OCTAL a more complete alternative to
>standard modules like XMs.  If you could just load any OCTAL file into a
>standard type of OCTAL player without needing to go and collect hundreds
.of machines, that would certainly simplifiy things.  But, then if you are
>including all the code for all those machines in the track, that track
>would be rediculously large.  Especially when you take into account wave

No, I didn't mean to imply that any code would be included in Octal song
files (the security implications are obvious.) I meant that there would be
guidelines on how to ensure that machine authors don't break people's song
files, and how to make the machines available so that if someone does need
to find machines in order to render a song, it will be easy even if the
platform isn't the same.

There's not much that can be done about the wave size. I anticipate that
MP3 will be a more popular exchange format than Octal's files---the file
format is primarily to save your own work in (possibly huge) files whereas
you can distribute a much smaller MP3.

I'm not sure how a drum machine (with its own samples that you can't use
in other machines) would work in Octal unless you compiled the waves in.
All the waves are globally shared for all machines to use.

>my system, so please make the option to save machines inside the track
>optional.  In Buzz its already optional to not save wave-files inside of

Don't worry, there was never a plan of saving machine code in Octal files
:-).

>I can understand your fear of updating a machine and then basically
>losing your track due to an incompatability, but thats more due to sloppy
>development in my opinion.  We should make a new convention for OCTAL in
>which if you change the paramaters, you change the module name, even if
>only slightly.  So, Octal_Tracker would become Octal_Tracker_2 if you

That also sucks because then you need to find some specific minor version
number. I have several songs I can't even load because the machine author
stopped distributing that version number, or even didn't save the old
version. Songs shouldn't break because the developer adds a new parameter,
it should just work with the new version of the plugin. That's one reason
why the version # will be a separate field from the name... the long name
of the plugin shouldn't change.

I think it would be better to just ensure that the names of tracker
columns are unique within a machine, and go from that when saving/loading,
so that the ordering and number of parameters won't affect it.

>a standardized database of machines that can be accessed from within

This is the thing I was talking about with "OXAN", sort of like CTAN or
CPAN, where it's on the web and you can use wget to grab the source from a
PHP script (keying on the name.) Very doable.


-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]