| |
cadaver
Registered: Feb 2002
Posts: 1160 |
NinjaTracker released at last...
Took a little longer than expected, but now NinjaTracker (with 10 rasterlines playroutine) is released. Not very userfriendly (as there's no instrument-data, only tables, tables and tables...) so approach with caution!
http://covertbitops.c64.org/tools/ninjatrk.zip
Sourcecode included, so customization is possible. Remember to do changes to both the editor's internal playroutine and the packer/relocator's playroutine (saved with packed tunes) |
|
| |
CyberBrain
Administrator
Posts: 392 |
You forgot do add it to CSDb!!!
I've done it for you though, but you might want to inspect it.. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Thanks :)
I was too lazy to do that, after coding it intensively in the last few days.. |
| |
Six
Registered: Apr 2002
Posts: 293 |
Nice tool. It's fun to tinker with the settings while it's playing too.
BTW - Have you ever considered doing a goattracker-like tool for the 128 in 80column mode?
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
No, because I don't have a C128 :) |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
@cadaver
How long it took you write Ninja-"Tracker"?
Did you wrote the playroutine first? Or have you designed the interface/handling first?
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Definitely playroutine first. Total process took a few weeks I guess. Why, are you trying to calculate codeslave salary? |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
NO!
I'm just interested. :)
PS. Well, I would design the interface first. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Interface IMO has not necessarily much to do with playroutine architecture & musicdata. After all, you could "edit" a song for any playroutine by just fiddling with a raw hexadecimal memorydump :) Or a more humane example, JCH editor could just as well display tracks & patterns separate, while having same musicdata & features. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
I think interface-design MUST come first, because it exactly will tell you how to code (afterwards) the player.... :)
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Actually one has to answer two separate questions ..
1) what do you want to be able to do in the music (playroutine)
2) how to command those abilities in the easiest & most powerful way (editor interface)
It could be argued that the features must be at least subconsciously known, before an interface can be designed. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: I think interface-design MUST come first, because it exactly will tell you how to code (afterwards) the player.... :)
This can be the case for modern PC music systems with real-time calculated audio and nearly unlimited degrees of freedom.
For a limited output device (SID) it is essential to be able to control details, hence the interface has to be player centered.
The natural way is then to program a good player, make a few test songs in it without editor (or with a rudimentary editor), and then possibly code a real editor if it's good enough to be used on more songs. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Quote: This can be the case for modern PC music systems with real-time calculated audio and nearly unlimited degrees of freedom.
For a limited output device (SID) it is essential to be able to control details, hence the interface has to be player centered.
The natural way is then to program a good player, make a few test songs in it without editor (or with a rudimentary editor), and then possibly code a real editor if it's good enough to be used on more songs.
Ok, this is maybe true! :)
Personally I would prefer real-time calculated stuff. :) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Quote: Ok, this is maybe true! :)
Personally I would prefer real-time calculated stuff. :)
And how is this relevant to whether player or interface gets designed first?
Maybe we should need a nata-FAQ so that he doesn't need to repost in multiple threads what he likes :) |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Quote: And how is this relevant to whether player or interface gets designed first?
Maybe we should need a nata-FAQ so that he doesn't need to repost in multiple threads what he likes :)
Heeee!
For me it's relevant! |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
For example, Sadotracker was coded player first, and it has realtime calculated vibrato & slide. Ninjatracker was also coded that way, and it doesn't have. So, your point was?
Btw. interface tells nothing of how to spread playroutine workload on successive frames, or how to encode the patterndata for best memory usage :) |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
If Nata prefers interface to be designed first then maybe he could make a fully working interface to show us how it should be.
I found when trying to make a music system (I got bored making the editing system so I stopped) that I had to adjust interface to make it more workable and more logical for the player. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Actually, at the moment I'm experimenting around with interfaces. It's quite a hard task to make something powerful, but with easy handling. |
