| |
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. |
|
... 19 posts hidden. Click here to view all posts....
|
| |
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: 422 |
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 |
| Previous - 1 | 2 | 3 - Next |
