| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
GoatTracker and GoatTracker Stereo new features
Im currently implementing the following features into GoatTracker and GoatTracker Stereo:
- /Q command line option for setting equal divisions per octave that differ from 12.
- /J command line option for setting different note names.
- /Y command line option for setting a path to a Scala tuning file.
- Small color changes to the pattern table for better readability.
- Isomorphic key layout.
- Switch between mono mode and stereo mode.
- /w command line option for setting 4 different window sizes.
Actually I can share a Windows build with sources if there's interest.
For further development of GoatTracker: What are your feature requests? Please let me know and I will see what I can build into GoatTracker. |
|
| |
spider-j
Registered: Oct 2004
Posts: 443 |
Reminds me of something on my everlasting todo list ;-)
Colorscheming support would be ace. I once did a dirty hack for myself but never got around cleaning it up so far:
http://gt2fork.jansalleine.com/ |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quote: Reminds me of something on my everlasting todo list ;-)
Colorscheming support would be ace. I once did a dirty hack for myself but never got around cleaning it up so far:
http://gt2fork.jansalleine.com/
Yes, colorscheme support can be done easily. I put it on my list. I saw you extended the colorscheme in the wavetable, pulsetable and filtertable. That's a great idea! |
| |
Mixer
Registered: Apr 2008
Posts: 421 |
Not that I use GT much, but i might.. if...
Redesign the instrument edit. We read horizontally, not vertically or randomly.
a) instruments viewed as list, parameters horizontally
01 00 00 00 ..
02 00 00 00 ..
instrument expanded
03 00 00 00 00 00 01
wftablesection xx xx xx xx
pulsetable section xx xx xx
vibrato section xx xx xx
filters section xx xx xx
b) Primarily only instrument-relevant parts of the wf/pulse/filter/frq table visible. (optimizations can be done later)
c) regarding scaling: viewing distance vs. screen size should be the determining factor for the size of elements on screen, not resolution and such technical details. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
@Mixer: tables in GT are pairs of bytes hence putting them horizontaly is kind of missed idea ;) |
| |
Mixer
Registered: Apr 2008
Posts: 421 |
@Jammer: indeed, or are they 16 bit words, or are the bits split some other way depending on their encoding. Perhaps it is just too big a change. |
| |
JCH
Registered: Aug 2008
Posts: 193 |
I would like to see support for colors added to blocks of order bytes (or some split line or whathaveyou) to indicate an important change in the tune at this point. It would help a lot in tunes with A-, B-, C- pieces, bridges, etc. |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Ideas from the GoatTracker Lounge facebook group:
- custom fonts and/or bitmap backgrounds
- visualizer bars for filtermode, cutoff, reso and PW values like in SID-Wizard
- a dedicated auto-depth calculated detune table
I also want to merge the codebases of the 1-SID and the 2-SIDs versions. I think this will speed up coding and testing by factor 2. |
| |
Snabel
Registered: Aug 2015
Posts: 23 |
I would love to see visual representation of PW for all channels, cutoff and reso like in SIDwizard (and maybe even filter type) |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quote: I would like to see support for colors added to blocks of order bytes (or some split line or whathaveyou) to indicate an important change in the tune at this point. It would help a lot in tunes with A-, B-, C- pieces, bridges, etc.
I assume you are talking about the orderlist and not about the pattern table.
How many different colors would you need? There is no rightcklick/popup-menue for choosing colors (sure, I could code one).
I would suggest using only one additional color as a background color that keeps the numbers readable, even when they are selected (green) or actually played (red).
Another thing I would think about is that saving this colored regions would break backward compatibility of the .sng file format. |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quoting Mixera) instruments viewed as list, parameters horizontally
01 00 00 00 ..
02 00 00 00 ..
Do you mean the way CheeseCutter displays intrument data?
Quoting Mixerinstrument expanded
03 00 00 00 00 00 01
wftablesection xx xx xx xx
pulsetable section xx xx xx
vibrato section xx xx xx
filters section xx xx xx
b) Primarily only instrument-relevant parts of the wf/pulse/filter/frq table visible. (optimizations can be done later)
In GoatTracker, the wavetable, the pulsetable and the filtertable are independent from the instruments. That means, there is only one large wavetable that is used/shared by all instruments and by cleverly using the jump markers (by jumping from one section into another and by building chains while saving table space) you can do things that were impossible if every instrument would have it's on wavetable (e.g. like in SID-Wizard or DefleMask).
Quoting Mixerc) regarding scaling: viewing distance vs. screen size should be the determining factor for the size of elements on screen, not resolution and such technical details.
At the end there are pixels on a screen and every screen has one or more screen resoulutions you can choose from (and/or the OS provides resolution and/or scaling options). It's up to the user to set a screen resoulution that fits well and it is up to the user to choose a viewing distance that fits well. In the code I can only specify the width and height of graphical elements (actually in GoatTracker there are just chars/letters, a rectangular cursor and the mouse pointer). In the code, I can provide the option for choosing different widths and heights of graphical elements (e.g. width/height x 2, width/height x 3, and so on). |
| |
Mixer
Registered: Apr 2008
Posts: 421 |
Well, there is one large wavetable etc. - a technique used in many play routines. I am just saying that displaying the same data in a different way in the UI can make the ui better to use. Otherwise the UI remains just a trackview and a hex editor. |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quote: Well, there is one large wavetable etc. - a technique used in many play routines. I am just saying that displaying the same data in a different way in the UI can make the ui better to use. Otherwise the UI remains just a trackview and a hex editor.
Yes, GoatTracker is a hex editor. From my perspective, putting the wave/pulse/filter tables horizontally instead of vertically would give me less data on the screen. Why should I do that?
The actual vertically scrolling tables have a position pointer on the left side and work in the same way as the pattern table. The orderlist table instead works horizontally and for me it is much more confusing than all the other tables. For the sake of consistency I suggest turning the orderlist table in to a vertical one. Then each line in a table represents some data that is used in a given moment of time and the vertical order of the tables (from top to bottom) indicate the flow of time. The only data that can/should be displayed vertically are the instrument start parameters. Here CheeseCutter can be used as a blueprint.
From my experience I have to say that building instruments in DefleMask or FamiTracker (I guess one copied the other) gives a much better visual feedback because both trackers work with visual instrument-data representations in form of editable bar-graphs. The drawback here is that a separate window is needed to display all the graphs because they take up a lot of space. Personally I would like to see graphs but not hidden in separate windows. |
| |
Hein
Registered: Apr 2004
Posts: 933 |
Saving HR settings in the song. Dunno if it's allready there, missed out on the updates since 2.68. |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quote: Saving HR settings in the song. Dunno if it's allready there, missed out on the updates since 2.68.
Actually HR settings are is not part of a .sng file. I'm with you that all parameters that effect sound and playback speed should be stored in the .sng file. Be aware that his would break backward compatibility. |
| |
onebitman
Registered: Nov 2002
Posts: 47 |
importing and exporting of .mid files :D |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quote: importing and exporting of .mid files :D
Great idea! I also want to implement realtime MIDI input. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Quoting AhornbergI also want to implement realtime MIDI input.
You should contact Mr SID on that, I believe, as he already figured out MIDI input in Mac build ;) |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quote: Quoting AhornbergI also want to implement realtime MIDI input.
You should contact Mr SID on that, I believe, as he already figured out MIDI input in Mac build ;)
thx! |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
It'd possibly be nicest to use a multiplatform library for MIDI, like SDL is already used for screen output+audio.
rtmidi appears to be one: https://github.com/thestk/rtmidi |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
cant SDL do midi too? |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Not in the sense of relaying the MIDI messages to/from OS. sdl_mixer is able to play MIDI song files. |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
I think of using RtMidi https://github.com/thestk/rtmidi |
| |
Mr. Mouse
Registered: Dec 2001
Posts: 235 |
Goattracker needs the optional support of FM-YAM’s 9 channels and of course digi channel(s): Goattracker Pro. ;) |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
Quote: Goattracker needs the optional support of FM-YAM’s 9 channels and of course digi channel(s): Goattracker Pro. ;)
... and much more than DefleMask supports (and it should boil eggs and brew coffee for my breakfast) ;) |
| |
Flotsam
Registered: Jan 2004
Posts: 80 |
Late to the party as always, but I just started using GoatTracker a few weeks ago and the absence of Undo is driving me crazy (not really, just being a drama queen here). Looking at savesong method, it shouldn't be too difficult to implement X levels of history snapshots for someone who knows his/her way around C++. Being a C# guy myself, I couldn't even get it to compile with GNU make so I gave up.
Speaking of savesong... remembering the last active load/save folder or even just being able to set a default song folder in config would be nice. |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
@Flotsam Thank you for your input!
I really appreciate everyone who wants to contribute in developing GoatTracker.
If you couldn't compile with GNU make, what err-messages did you get? Did you try it on Linux or Win? |
| |
Flotsam
Registered: Jan 2004
Posts: 80 |
I'm getting this on Windows:
make (e=2): The system cannot find the file specified.
make: *** [goatdata.o] Error 2
I did google a bit and it seems that this could mean a plethora of different things, not necessarily that the goatdata.o file itself can't be found. I ran the command in the source folder and checked the paths in makefile.win and the common one. I have set the path to C:\Program Files (x86)\GnuWin32.
Anyway, as I said, I haven't done C++ and only know the basics, so my goal was to do something super dirty like hooking up the keys and on every keypress calculate a checksum of the song data and if it differs from the checksum of the last taken snapshot, add it to an array of snapshots. |
| |
Ahornberg
Account closed
Registered: Mar 2019
Posts: 13 |
@Flotsam Did you follow the readme.txt?
8. Recompiling
--------------
To recompile for Win32, you need the MinGW development environment, use the file src/makefile.win as makefile. |
| |
Flotsam
Registered: Jan 2004
Posts: 80 |
Rule 1: never, ever, ever read the readme.txt file. Never.
Thanks, I'll have another go at this once I've taken care of my family obligations. :) |
