| |
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 |
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:I only would like to compose SID music, leave the programming & gfx.
WHAT ?! no Mortal Kombat ?:( |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hmmm, I would be the happiest if I will ever have that much time for finishing MK, you know it's in early state...
...maybe later with some volunteers' cooperation..
Miaking a tracker is in priority against games for me at the moment.
(until that you should play the excellent hu-game, Long Life)
Hermit Software Hungary |
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
i can't wait! hmmm, i would like a sid ripper function to rip sids straight to the editor for disection!! ;) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
If at all possible, more than 32 instruments would be preferable. |
| |
Adam
Registered: Jul 2009
Posts: 323 |
I agree with Cadaver - More instruments the better!! Thou, What would be very nice for any new SID tracker for the C64 or PC would be 'MIDI' keyboard support. I have a MIDI keyboard and long to use it for constructing SIDs. VICE supports MIDI pretty well IMHO so I guess it's a practical idea to suggest - you'd make a lot of SID musicians very happy id imagine if you guys included this type of support ;) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Adam: SDI 3 - just wait for it.. |
| |
booker
Registered: Jul 2003
Posts: 334 |
cadaver: Why do you need 32 instruments? 8-) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
I've probably never come even close to 32 myself (on any editor I've used), but it's somehow anxiety-inducing to know you can run out of instruments by eg. creating lots of chord arpeggio variations of the same instrument. You can "cheat" the limit by putting a wavepointer-change command to each note (if supported), but then the tune will probably pack worse.
32 is often used as a limit if instruments are stored into a 256 byte table, 8 sequential bytes per instrument. But IMO that's inflexible: sometimes you might need more parameters, sometimes less (especially if player code will be dynamically linked to include/exclude certain features as needed)
|
| |
Kristian
Registered: Apr 2002
Posts: 126 |
Quote: Adam: SDI 3 - just wait for it..
Yeah. I was testing it over at GRG's place the other day. Very neat stuff! |
| |
Linus
Registered: Jun 2004
Posts: 639 |
@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 :) |
| |
GT
Account closed
Registered: Sep 2008
Posts: 308 |
Amazing that people don't know how powerful the SDI editor is. You can attach just ONE instrument if you want, to all the arpeggio variations. And for arpeggio, you can use instruments $20-$2F, if you'd like, and leave $00-$1F ready for the sequencer only. Packer will take care of those unused, and clean it all up. Regarding multispeed, you can delay the arpeggios. So totally in SDI, you have $2F instruments, and you can create $1F arpeggios besides this. You can also blend arpeggio table with wavetable. And this was allready done in 1992 in GT-Editor, happy composing. :-) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
I have squeezed 2 full instrument sets into SDI 2.0
1st is pop music soundset that i tweak for every tune
2nd is orchestra soundset that i also tweak for every tune
Both sets use all sounds, 32 - and i have 12 general arp programs, that cover most, and which i tweak.
In the 6x soundset i use, i have only reached byte $E4, so still a few bytes left for more wavetable..
Although i have never used it, the repeat wavetable section command is usefull - can save lots of space. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11352 |
and all that without knobs and sliders! |
| |
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. |
| |
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 |
| |
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 |
| |
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. :-) |
| |
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 |
| |
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 |
| |
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).
|
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Release tracker first, start csdb thread after? |
| |
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 :-) |
| |
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. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
First you should spend enough time, to exploit all possibilities in the editors you have now - learn to use them properly.
The whole process how to make things easier, or combine things, is a very long one. Ask Geir and Jeff :D they could have coded and relesed a new editor in 1 month, but it takes a lot longer, because getting the new ideas transformed into something sensible to use, just takes time, as there is lots of considerations.
Hermit: have you checked Asterion SID tracker ?
it has some macro tables, so you can make funny stuff. But it's very longhaired to master this editor..
|
| |
Conrad
Registered: Nov 2006
Posts: 847 |
It's amazing how complicated players and editors have got... it's all good having an editor with EVERYTHING a general composer can wish for (as SDI does according to most of you), but if you're a coder too, nothing can beat your own creation, coz you are its master anyway. So quit arguing and start coding!... Actions talk more than words. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
No need to invent the wheel 20 times.. |
| |
Soren
Registered: Dec 2001
Posts: 547 |
Jan: well, sometimes I wish I had more sparetime, as I prefer doing longer coding sessions... it's much easier to work that way for me. :-) Anyways, I got a good deal done in my summer holiday, so I just need to find some time again... Been boozing+partying a bit too much lately.
I always found it nice to code one's own music tools and I guess many more feel the same way. So probably the wheel has been reinvented quite a few times. :-) |
| |
Hermit
Registered: May 2008
Posts: 208 |
I opened this thread, because I would like to do it as an "open project"...
Of course, I started doing my new player first for my demanding wishes, but I also got a lot of ideas from people at this thread... and I can start doing it by knowing what musicians generally need...
I also read through the help of all best tools, and collected every function..and now I'm around continuing the player with more knowledge..
Still waiting for wishes, and will try to implement...if it's logical and won't use extreme rastertime..
Hermit Software Hungary |
| |
Hermit
Registered: May 2008
Posts: 208 |
E.g what do you think about GT2's capability to have tempo settings for each tracks individually..is it useful? do composers use this function?
And would the speedtable be more steps, or is Funktempo (2 tempos swinging) enough usually? BTW, it's not hard to implement more tempo steps ..
Hermit Software Hungary |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
I'd actually prefer explicitly specified note durations :) but then I guess it's not a tracker anymore.
If the player can manage "tempo 1" ie. each pattern tick can be even only 1 frame long, then need for individual channel tempo can be circumvented, and you could go with a global speedtable. Still, speedtable for each channel would offer most flexibility. Think for example a triplet lead passage while rest of channels plays a 8/8 beat.
In any case, would not recommend limiting to 2-step tempo only.
But still, the most motivating system is always the one which has exactly the features *you* need, so I don't know how useful it's really to ask for suggestions here. A player only is easy to code, but one definitely needs motivation for a whole editor :)
|
| |
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 :) |
| |
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.
|
| |
Soren
Registered: Dec 2001
Posts: 547 |
Dane: I was thinking exactly the same... atleast there's duration packing in my packers :-) |
| |
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.
|
| |
Linus
Registered: Jun 2004
Posts: 639 |
That's exactly my point, Stein :)
|
| |
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. |
| |
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 |
| |
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. :) |
| |
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 |
| |
Hermit
Registered: May 2008
Posts: 208 |
Coming soon :)
------------
hermit |
| |
Soren
Registered: Dec 2001
Posts: 547 |
Hermit: Looking forward to that. :-)
|
| |
Digger
Registered: Mar 2005
Posts: 427 |
Yiiiiiiihhhhha! That's a great news Hermit. I've been waiting for this editor for around 14 years (no pressure) ;-) |
| |
Martin Piper
Registered: Nov 2007
Posts: 718 |
I added the ability to switch between pattern editing modes in Music Studio 2.1.0.7
Lately I've been thinking of what can be done to improve instrument editing and adding some form of MIDI input. But I have no firm plans yet for the next version.
So since I'm just a programmer I really could do with input from musicians. |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi Guys. I owe you with some update about SID-Wizard project:
I had some lags due to other hobbies and tasks, but when I have some time I always return to finish the code of SID-Wizard.
Since my last post I nearly finished the in-place compression/decompression routines for the workfile, so the saved workfiles will be small. Soon I continue with saver/loader menu and subroutines, then some player code optimisations are coming. (And a separate packer/optimizer to further optimize and create/relocate SID and PRG tunes out of compressed workfiles.)
I nearly finished the user manual in LyX which can be exported to PDF/html and even plain text... there are some minor known bugs yet in editor which can cause corrupt data.
I'll release a beta/1.0 hopefully before xmas, with the source codes, so the project will go open-source. So everyone will be able to optimize code or add features....
|
| |
Flex
Registered: Feb 2002
Posts: 110 |
Really looking forward for this as I'm very impressed by all the work you've done so far Hermit. |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi, Guyz
I was quite silent for some months, but it's due to the work I've put into player code and corresponding tracker-code optimization/rewriting of SID-Wizard. There are so many features that I had to solve in very few cycles to keep rastertime...mainly managed it, I guess.
Anyway, the great news is that the release is coming soon, much later than I expected some months ago, but I estimate around one month (including helpdoc and example tunes/instruments).
Stay tuned, and may all of you keep your attitude to C64... |
| |
DustBin
Registered: Jun 2006
Posts: 12 |
Can't wait for it! ;-) |
| |
MC
Account closed
Registered: Jul 2009
Posts: 71 |
Take your time m8 the tracker only gets one shot at making a first impression. I know what its like with work and other stuff getting in the way of c64 related stuff. 2nd time now I got an email from this website its been 5 months since I visited and my account was again to be erased...
I'm very interested in checking out your wizardry.
|
| |
Digger
Registered: Mar 2005
Posts: 427 |
Hermit! You're my new hope! :) Great news. |
| |
Hermit
Registered: May 2008
Posts: 208 |
You're right with that free-time stuff. That's why I'll work in less hours at workplace as soon it will be possible. It isn't worth for me to give my lifetime for a bunch of money. I think in this rushed world only sceners can understand what I mean by this.
but, back to the topic. I'm on holiday for this week, and it's almost possible to finish the code (relocator and some minor bugfixes are left to solve).
I'll release the pack in 1-2 weeks hopefully, with some test-tunes and instrument-pack made by me and fellow sceners. And a video-tutorial is in plan too, and if you check out Arok Party homepage, you can see I'll keep a seminar in live as well.
Keep your brain and hands warm, the release is near :)
|
| |
MC
Account closed
Registered: Jul 2009
Posts: 71 |
Great maybe I can toy with it and get some stuff out before X2012. |
| |
Hermit
Registered: May 2008
Posts: 208 |
Dear Sceners
I didn't forget You. I'm implementing a bit more feature into SID-Wizard than what was planned a month ago. Not on the C64 part but on the x86 part, where I have to write some C code from scratch. You'll see... :{) |
| |
zscs
Registered: Sep 2010
Posts: 48 |
Well, we can wait 1-2 days more. :P |
| |
Digger
Registered: Mar 2005
Posts: 427 |
Hermit, yo got me sizzlin'! :D |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi guys.
Well,
In the last days I decided to add some more extras to SW, and it seems I'll have the dedicated time for it in next days. That will delay the release of SW 1-2 weeks, but it will be worthy...
Sorry for all the promises which were about unrealistic release dates. I learned it's better not to promise until it's not really sure. The time needed for complex careful coding is always 5 times underestimated according to my experience. ...Stay cool. :)
|
| |
Digger
Registered: Mar 2005
Posts: 427 |
Haha last lap Hermit, fingers crossed! :) |
| |
Frantic
Registered: Mar 2003
Posts: 1646 |
Ok.. See ya in 5 years then! |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi Frantic! It's not like that ;) Fortunately I'm really at the end of this project, mainly some bugfixes are left. (But the next project, the FPGA based PC might take 5 years. ..) |
| |
zscs
Registered: Sep 2010
Posts: 48 |
Quote: Hi Frantic! It's not like that ;) Fortunately I'm really at the end of this project, mainly some bugfixes are left. (But the next project, the FPGA based PC might take 5 years. ..)
Hi Hermit,
Any news on this topic? :P |
| |
NecroPolo
Registered: Jun 2009
Posts: 231 |
Quote: Hi Hermit,
Any news on this topic? :P
I assume, sooner than you would think :) |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi...
Well, NecroPolo is right, my plan is to release SID-Wizard next week, because I'll keep a presentation about it at Arok Party on next Saturday. :)
Still working hard on some fixes, but fortunately this week is mine entirely and have the required contiguous free time :)
Thanks for being patient.
cheer$
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
This thread is nearly 3 years old now, so finally a new tracker is finished soon ? dont hurry, better be sure it is bugfree :) great work Hermit! |
| |
zscs
Registered: Sep 2010
Posts: 48 |
Wow, sounds great! :)) Thanks for the info. ;) |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi there.
I uploaded a test-release on 7 July.
SID-Wizard V1.0 RC
I want to start a new thread where further suggestions/ideas can be discussed.
If you'd like to code for SID-Wizard we might discuss how cooperation could be arranged to work on it together.
I got some idea at first place from Soci at the party, and I'll try to sketch a visual arrangement of the source-files for better understanding of the code-structure (which might be rearranged if we can find better ways).
**** The new topic is started at: ****
SID-Wizard - further development
|
