| | 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....
|
| | Hermit
Registered: May 2008
Posts: 208 |
Yes, now I see. Thinking about triplet solo and fast passages, the individual track tempo-tables really would be useful, and seems not so hard to code...I think I'll try enabling this function..
Of course, I would do the tracker as comfortable as possible..but the first thing I have to reach that the player would have the possibly least limitations...
Hermit Software Hungary |
| | FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
Individual tempo is the most realistic towards real music as real instruments are played at different speeds to each other.
FlimboFrost!
|
| | SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Visually, i think that voice 2 running faster than voice 1, would be very crappy in practical use. When you sync up snare hits, notes etc., just just use 1 tempo and this works fine.
Notice that SDI has free length sequences, so f.ex voice 1 has 7F long sequence, and voice 2 has 4 notes long sequence.
You can make it any way you want, and sync your stuff this way.
I dont think your idea will be good, but ofcourse, if you want to try it, you have to make it :D |
| | 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.
|
| | 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' :) |
| | 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 |
| | 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. |
| | 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 |
| | 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. |
| | 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 :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next | |
