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

Welcome to our latest new user Rodrigo Yeowtch ! (Registered 2024-11-24)

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 03:47

Conjuror

Registered: Aug 2004
Posts: 168

How about a human readable file format.

Playing with GoatTracker at the moment. I'm sure I'd find easier if I could just type in the notes in a text editor. Then again I'm not experienced using trackers.

2009-09-09 06:25

Linus

Registered: Jun 2004
Posts: 639

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' :)

2009-09-09 07:48

Hermit

Registered: May 2008
Posts: 208

All in all, I will give the possibility for individual track tempo-tables, of course by keeping the compatibility & ease of use with simple global speed setting commands / adjustabe initial speed-tables per subtune...

There are some other tips, we can discuss, if theye're needed or not:
-A 4th track just for Filter-cutoff or RESO/bandswitches? The value in this coulmn wouldn't overwrite the instrument or pattern filter settings, but would be added/ORA-ed to them..
-ADSR SET / GATE ON order is adjustable for each instruments in JITT64. Is there an optimal order (IMO ADSR then GATEON), or should instruments have this parameter?
-Two FX columns for each tracks? Then FX-es would start&run paralelly.(Of course they just eat memo, if they're there.)
-The 1 byte note coulmn could contain pointers to predefined or instrument-related arpeggio-chords in tables...the chords could be catched easily into chord-tables by pressing&holding note-keys in the desired arp-order...
(Note byte: value $01-$60-8octaveX12notes, $60-$7c-chords, 00-NOP, $7D-gateon. $7e-gateoff, 7f/ff-signs pattern's end, MSB ($80) bit signs tied note&instrument column's existance).
-Pattern FX to switch on/off (or EOR) RINGmog or SYNC bits on the actual tracks?

Hermit Software Hungary

2009-09-09 08:57

Stone

Registered: Oct 2006
Posts: 172

Quote: All in all, I will give the possibility for individual track tempo-tables, of course by keeping the compatibility & ease of use with simple global speed setting commands / adjustabe initial speed-tables per subtune...

There are some other tips, we can discuss, if theye're needed or not:
-A 4th track just for Filter-cutoff or RESO/bandswitches? The value in this coulmn wouldn't overwrite the instrument or pattern filter settings, but would be added/ORA-ed to them..
-ADSR SET / GATE ON order is adjustable for each instruments in JITT64. Is there an optimal order (IMO ADSR then GATEON), or should instruments have this parameter?
-Two FX columns for each tracks? Then FX-es would start&run paralelly.(Of course they just eat memo, if they're there.)
-The 1 byte note coulmn could contain pointers to predefined or instrument-related arpeggio-chords in tables...the chords could be catched easily into chord-tables by pressing&holding note-keys in the desired arp-order...
(Note byte: value $01-$60-8octaveX12notes, $60-$7c-chords, 00-NOP, $7D-gateon. $7e-gateoff, 7f/ff-signs pattern's end, MSB ($80) bit signs tied note&instrument column's existance).
-Pattern FX to switch on/off (or EOR) RINGmog or SYNC bits on the actual tracks?

Hermit Software Hungary

Quote:

-The 1 byte note coulmn could contain pointers to predefined or instrument-related arpeggio-chords in tables...the chords could be catched easily into chord-tables by pressing&holding note-keys in the desired arp-order...
(Note byte: value $01-$60-8octaveX12notes, $60-$7c-chords, 00-NOP, $7D-gateon. $7e-gateoff, 7f/ff-signs pattern's end, MSB ($80) bit signs tied note&instrument column's existance).

Don't you need a base note for the chord as well? Or do you plan to have chords specified as note values rather than intervals? Chord memory would fill up pretty quick in that case...

EDIT: The quoting in this forum really sucks.

2009-09-09 10:05

Hermit

Registered: May 2008
Posts: 208

You're right, the $60-$7C should sign the base note somehow, and the chords should be intervals in the chord-tables.

I found out three possible alternatives by now:

1. The $60-$7c is around 2 octaves in interval..this would give 12 base notes X 2 chord types (minor & major). The chords could be predefined, and instrument data would
contain the type & octave of arpeggio - e.g. 0-4-7 or 0-4-7-c or 0-4-7-4, $fb-0-4-7, etc. in case of major chord
The problem with this approach: Not so flexible in regards of octaves and arp-type, and lacking 7th,9th,etc. chords. Maybe the predefined arps could be changed, and of course instruments would have the conventional arp-table, and this function would be just a plus to make work easier.

2. The note would stay the same in note coulmn, chord (minor or major) could be called as pattern FX. The FX-value could contain predefined chord/arp-type or pointer to arp-table.
It's similar to change-arptable-pointer FX, but specified to chords, and wouldn't affect Waveform, just pitch....

3. Capturing notes from C64-keyboard or MIDI-keyboard pressed&held&released keys in wished arp-order. They could be stored in place of one note (in one row), and storing only base-note with the relative-intervals, we could save memory.(if no bigger arp-pitch up/down jump than $F (15) halfnotes, then a nybble is enough for an arp-step.)

None of these is really a complete, comprehensive & final solution, but they can help thinking to find out a comfortable & simple combination of solutions for arps/chords..

Hermit Software Hungary

2009-09-09 16:17

booker

Registered: Jul 2003
Posts: 334

Perchaps it would be neat to put the arp calculation into the editor. So no predefined arps, just user would choose what chord type to get (+base note, +base instrument or wv/pulse/flt/ADSR/hrestart ect) and editor will calculate the relevant arppegio and link it to relevant tables.

2009-09-09 16:20

booker

Registered: Jul 2003
Posts: 334

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' :)

Nice :)

2009-09-09 18:10

Dane
Account closed

Registered: May 2002
Posts: 421

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.

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

Refresh

Subscribe to this thread: