[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-07 15:08

GT
Account closed

Registered: Sep 2008
Posts: 308

Quote: and all that without knobs and sliders!

Just a comment to harass people ? Totally off topic.

2009-09-07 15:24

Jammer

Registered: Nov 2002
Posts: 1335

Quote: @Cadaver: I learned to live with a max of 32 instruments by using wavetable pointers. What bugs me more is the 'small' wavetable :) One of the reasons I dropped multispeed :)

you'd be scared seeing how little instruments i usually have :D

2009-09-07 16:08

Hermit

Registered: May 2008
Posts: 208

The MIDI is a great idea. I planned my "HMTSYNTH" for MIDI-keyboard at the beginning, and
(with screen $d011 off) I managed to process the 32768Hz midi signal directly connected to USERPORT or CASSETTE (CPU) port data & NMI/irq pins. That way I could play notes from MIDI..but there wasn't enough CPU time left for complete player routine or tracker code to run..

If I could use my MSSIAH's MIDI port somehow ... or maybe Kingfisher's MidiSlave device could be midi to note interpreter...or maybe an other C64 connected to the main C64 could process the midi-signal....

About Instrument-problem: If only arpeggios the reason for more than 32 instruments, the SDI approach is fine, but what about having the typical arpeggio chords (minor/major,etc.) prestored for use?
Or I think the instrument/table limit problem could be solved if all instruments were a separate unit with own tables and parameters. So no need for wf/pw/ctf/hr tablepointers, instead 2 byte pointers could sign the instrument-datas' startaddress in memory- like for patterns-
This way the flexible memory usage should be achieved in realtime without need for compression/optimization later, and we don't need to play with pointers & common tables...
The only disadvantage of this approach in my opinion, that we couldn't use common tables for more instruments...but more arpeggios could be described for one single instrument, and there would be enough pattern FX-es not to waste a new place for the same instrument just for less sustain level or other arpeggio table (just as in SDI...)

I hope I expressed myself clearly...any opinions about this?

Anyway, a mouse/joystick pointer support would also fasten the work with the tool, like GT2/FT2..

Hermit Software Hungary

2009-09-07 16:37

GT
Account closed

Registered: Sep 2008
Posts: 308

Quote: The MIDI is a great idea. I planned my "HMTSYNTH" for MIDI-keyboard at the beginning, and
(with screen $d011 off) I managed to process the 32768Hz midi signal directly connected to USERPORT or CASSETTE (CPU) port data & NMI/irq pins. That way I could play notes from MIDI..but there wasn't enough CPU time left for complete player routine or tracker code to run..

If I could use my MSSIAH's MIDI port somehow ... or maybe Kingfisher's MidiSlave device could be midi to note interpreter...or maybe an other C64 connected to the main C64 could process the midi-signal....

About Instrument-problem: If only arpeggios the reason for more than 32 instruments, the SDI approach is fine, but what about having the typical arpeggio chords (minor/major,etc.) prestored for use?
Or I think the instrument/table limit problem could be solved if all instruments were a separate unit with own tables and parameters. So no need for wf/pw/ctf/hr tablepointers, instead 2 byte pointers could sign the instrument-datas' startaddress in memory- like for patterns-
This way the flexible memory usage should be achieved in realtime without need for compression/optimization later, and we don't need to play with pointers & common tables...
The only disadvantage of this approach in my opinion, that we couldn't use common tables for more instruments...but more arpeggios could be described for one single instrument, and there would be enough pattern FX-es not to waste a new place for the same instrument just for less sustain level or other arpeggio table (just as in SDI...)

I hope I expressed myself clearly...any opinions about this?

Anyway, a mouse/joystick pointer support would also fasten the work with the tool, like GT2/FT2..

Hermit Software Hungary

Except for the MIDI. Like Macro Player does, you mean.
SDI has ADSRs features in the sequencer. Read the manual. :-)

2009-09-07 17:05

Hermit

Registered: May 2008
Posts: 208

Yeah,yeah, I didn't mean the ADSR thing for SDI, oppositely, I wrote 'just as in SDI' = 'the problem could be solved as the same way as in SDI" .
And just to prevent misunderstandings, I never would say any wrong words for any of the existing great tools, I respect your work..and I read the SDI manual, and consider SDI very sophisticated and featureful..

Other thing I would ask from all musicians to make statistics, which form of pattern fx you prefer:

-Is it better, if you have to write the fx into all rows that you would hear it in? (like in gt2)
-Or the opposite: Is it batter to only write fx (e.g. vibrato) once into the pattern, and play it till next note?

OR maybe all pattern FX-es would behave different in regards of these two modes?

And if there are more fx-es to run paralelly (only possible with the 2nd methd), would they be mixed or one FX should stop the previous FX-es execution? (I personally don't think so)

And one other thing: Would we add the instrument parameters with FX-es or just overwrite them. E.g. the instruments own vibrato could be mixed with the Pattern-FX vibrato? Or pitch-slide could be mixed with vibrato or not?

In my opinion it's better to mix all the corresponding running pattern & instrument FX-es into one summary. I mean it for pitch, filter-frequency, pulsewidth, or anything..mixing more fx-es could give more possibilities & flexibility

Hermit Software Hungary

2009-09-07 17:21

Hermit

Registered: May 2008
Posts: 208

I just checked the Macro Player.

Yes, my approach would be something similar, the instrument would contain only that's needed, and the tracker could give an user friendly interface to prevent the musician from writing commands..somehow..e.g. with predefined areas on the screen, and memory would be only filled for the specific tables, when they contain data.

And to solve the common table issue, the instruments could have the possibility to be linked to another instrument..say, one instrument could use another one like a subroutine, or could use one/more of that instrument's tables :)

Now it seems a bit complicated, but i think there should be a simplified way for linking instruments...I don't think we would link instruments most of the time , because when we load an instrument from disk, it will take its own place (like in gt2)

(one time i tried Sosperec editor and it seemed to have own expandable table for all instruments...)

Hermit Software Hungary

2009-09-07 19:13

ice00

Registered: Apr 2002
Posts: 54

Quote:

-Is it better, if you have to write the fx into all rows that you would hear it in? (like in gt2)
-Or the opposite: Is it batter to only write fx (e.g. vibrato) once into the pattern, and play it till next note?

I replay in this with a technical point of view, not like a better choice from a composer point of view ;)

The advantage of second method is that you can have more different effects started in same note duration, eg:
TICK 1: Effect1 start
..
TICK 1+x: Effect2 start
..
TICK 1+x+y: Effect3 start
..
TICK 1+x+y+z: New note (all effects stop)

instead in the first you have only one:

TICK1: Effect1,step1
TICK2: Effect1,step2
...
TICK 1+x: Effect1,stepx (can't start Effect2)
...

Maybe with the first methods you can have more control on each steps effect, while with the second is not so common to start more that one effects at time (but maybe control the vibrato, the pulse or the filter at row level,at same time, and not in instrument can be usefull).

Other consideration can come from an implementation point of view: rastertime consuming (The first seems to be better for save rastertime at a first approach)

Finally, point 1 can have even more effects started in same row (if implemented like in Cybertracker) with a special multi instructions commands (but at a cost of more rastertime usage).

2009-09-07 19:41

Dane
Account closed

Registered: May 2002
Posts: 421

Release tracker first, start csdb thread after?

2009-09-07 20:15

Soren

Registered: Dec 2001
Posts: 547

Ice00: It's nice to be able to do more commands per tick.
Fortunately for me, my latest player has several commands that can do more than just one thing... apart from that I have an instrument subtable where you can do a lot of things aswell, either with delays inbetween or at the same time.
Still I have tried to keep everything as simple as possible, as to me it gets painfull to work with, if there's too much to remember and so.
Still one doesn't need a lot of features to do a nice tune, but "only" some skills :-)

2009-09-07 20:23

abaddon
Account closed

Registered: Apr 2002
Posts: 28

If I were to make a new editor, I'd take the GoatTracker route and make it run on PC. It's relatively simple to link reSID to a C64 player engine running on 6502 emulator. Take a peek inside the GT source to see how it's done. Making a complete editor in machine language is very time consuming. This way, one gets all the goodies and comfort of modern high level languages and the extra processing power that PC has. I got a crude self-made editor working like this. Nowhere near the GoatTracker level, and never will be, but the interface suits me better.

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

Refresh

Subscribe to this thread: