[CSDb] - User Forums - Ideas for a NEW TRACKER

You are not logged in - nap

CSDb User Forums

Forums > C64 Composing > Ideas for a NEW TRACKER

2009-09-06 18:33

Hermit

Registered: May 2008
Posts: 208

Ideas for a NEW TRACKER

Hi, Guyz

I have the same problem as others have nowadays in this fast industrial world: Not too much of FreeTime...
I only would like to compose SID music, leave the programming & gfx.
Only one problem is still in my way: Need for a reliable, full featured music editor.

There are a lot of great tools, I think the best are: XSID, SDI, JCH, SID-Factory, DMC5, Goattracker, (BullSID coming?)

I made a lot of comparisons among them, and Goattracker get the most point in regards of functionality (but not in all).
I like the tracker, but don't like emulated sound. Through
PC64 cable or HardSID you can use real SID, but just under the buggy Windows. I don't know about Linux drivers for these. And don't want hangs/losses anymore while composing.
(BTW I had issue with GT2 in Linux, I couldn't save, maybe the Linux wasn't configured well or the GT2 package was compiled wrong...). A MAC is expensive for me, and I even can't say that MACOSx is as safe as C64..

There are some missing functions from the native C64 trackers, first of all, e.g. a simple function: saving an instrument, that you may made for an hour or so...
(DMC has this function if I know well.)

Other important things that are useful: keyjazz (hear note when typing), instrument-detune, MMC/IDE64 compatibility, multispeed, mute/solo tracks, definable HR-type & timer for all instruments....
Most of even the best trackers lacks one or more of these functions. Some have special keymappings to learn..

All in all, I decided to spend my freetime for writing a native C64 tracker that may have everything that a SID-composer needs.

Tha player routine is in half way, an now this is the point when you can come up with ideas your actual tracker is lacking.
Then in this forum we can discuss if it's possible and useful, and logical, etc...

E.g. let me to share my feature-ideas and the actual plans for the player and editor. These are not the usual features (as e.g. funktempo) but some special things:

PLAYER:
-------
-The player will handle the average maximums, 32 subtunes,
255 long orderlists, max.127 of 255 long patterns, 32 instruments.

-The patterns will basically contain only the notes, and
Instruments+FX-es+values only stored if they're there
(this way we have 4 columns per track in memory virtually,
the player can handle this format already.)

-Orderlists will contain data in similar way, so we have
a 2nd 'virtual' column for
transpose/repeat/jump/end and SUBTUNE-CHANGE commands

-I will implement 'Keyboard-track' command as I did in my
3SID tracker. Cutoff freq. can depend on note-pitch..

-Will try to logarythmize the Pulsewidth & Cutoff freq..
sweeps, making bass-filtering more detailed, and maybe
same table could be used for calculated vibrato/slide.

-There will be wavetable/pw/ctf programs/pointers also for
GATE-off, not only for note-on...

-Some compression could be achieved with signing long empty
places (zeros) with a number...

-Should we still use WF/PW/FI/HR tables, or own tables for
every instruments? (At least from editor view.)

EDITOR:
-INSTRUMENT SAVE function
-MMC64 & IDE64 compatibility (e.g. Sid Factory / SDI have)
-Waveform-displayer for instrument editor, filter/PW bars..
-Any ideas to make arpeggios easier? e.g. note based arps.
-Unused player code/pattern/instrument optimization (GT2)
-Possibility to save directly into SID format (as GT2 can)
-High resolution/interlaced characters or using borders to
have more columns and rows..
-Rewind-back/ loop-play function like in my 3SID tracker
-Memory usage displayer bar / counter / out of memo sign..
-Orderlist: long patterns' numbers displayed longer, so no skew when playing...
-Some help for ringmodulation (sign tracks, calculate f1+f2)
....

As you could see, these would be sophisticated features that could make SID-composing easier...and IMO, they're realizable, it's only question of time ...

Tell me bravely, if you have anything new to mention...

Hermit Software HungaryHermit Software Hungary

... 63 posts hidden. Click here to view all posts....

2009-09-09 18:10

Dane
Account closed

Registered: May 2002
Posts: 421

Quote: Jan: Not good, eh? For me an individual voice tempo option is essential to have, not only to implement triplets but also to save a lot of mem. When I realize a pattern looks like

c-3
---
d#3
---
f-4
---

etc I'll let it run in half of the original tempo and transform it to

c-3
d#3
f-4

That way I can cut one half of the pattern and save some bytes.

To demonstrate what I am talking about I put up a video http://www.youtube.com/watch?v=omFjhj9ZPxU

That particular tune would have grown too big for Crest's Crest Slide Story without that 'trick' :)

Hmm isn't this what packers are for? If I make a sequence like this:

c-3
+++
d#3
+++
f-4
+++

then the packer will automagically reduce it to three notes with longer duration. The only thing to look out for is spaces between notes - to always fill them with gate-on.

But then again, I use a different editor. Maybe I'm missing something rudimentary.

2009-09-09 18:32

Soren

Registered: Dec 2001
Posts: 547

Dane: I was thinking exactly the same... atleast there's duration packing in my packers :-)

2009-09-09 20:44

Stone

Registered: Oct 2006
Posts: 172

I think any sensible packer/compiler would translate running pattern NOPs or Gate-ONs to a duration value. Perhaps Linus was talking about saving pattern memory in the editor, in which case he has a very valid point if each pattern has a fixed blocksize allocated to it.

2009-09-09 21:41

Linus

Registered: Jun 2004
Posts: 639

That's exactly my point, Stein :)

2009-09-10 10:28

Dane
Account closed

Registered: May 2002
Posts: 421

Yeah, that makes more sense. I've had the same problem a few times but solved it with either splitting the tune in two or chopping sequences up into smaller pieces which were then recycled.

2009-09-10 14:45

SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238

Dane: well, EOD soundtracker could probably have been in 1 file at 7-10K if you have made it with SDI.

It's quite an achievement splitting a 14 minute tune to 9 ? 4K parts.. :D

2009-09-10 17:52

Dane
Account closed

Registered: May 2002
Posts: 421

Fifteen! And I think a lot of that came from the fact that the player was optimized with unlooped code. Make a version of the tune in 7-10k if you want, but I don't think you'll make it work in tandem with HCL's code. :)

2009-09-29 17:20

Hermit

Registered: May 2008
Posts: 208

What do you all think about the pattern-edit methods?

In my opinion, JCH's SEQ+Pattern method was a great invention, and I also like as it is implemented in XSID (switchable to orderlist with '=' ).

But if there is a possibility for individual track-speeds, it's hard to imagine the JCH method correctly working..or at least it wouldn't be easily followed by users..
(To keep syncronization, some (faster) tracks have to move faster than the others when they are scrolled at editing/playing...)

Editing differently fast tracks would be followable easier by the user with Goattracker's normal pattern edit method...

To keep sync in mind while composing, btw, the orderlist elements should be sensitively displayed in length (graphically?) to the tempo-change & pattern length.

The best would be if we can switch between JCH and GT pattern-editing mode in the tracker for our own taste..who knows, at the end it can happen :)

Hermit Software Hungary

2011-06-23 17:30

Hermit

Registered: May 2008
Posts: 208

Coming soon :)
------------
hermit

2011-06-23 18:14

Soren

Registered: Dec 2001
Posts: 547

Hermit: Looking forward to that. :-)

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next

Refresh

Subscribe to this thread: