Here

I have directly replaced the 2A03 with the SN76489 chip, and surgically removed all the expansion chips. The ultimate aim is to produce a diff against official version 0.4.6, which will prevent me from having to carry out all this atrocity again with 0CC-FamiTracker. The source repository will be available soon.

The Github repository is here

. All builds are available under the "Releases" tag. The most recent version is 0.2.2.

Read also the SnevenTracker statement here

.

What about .sgc?

Man... This makes me happy. :) FamiTracker interface for anything is always a plus!

SnevenTracker ;P

Some enticing things to consider:

- SMSj mode with YM2413 (VRC7ish)
- GG mode with stereo
- SGC export (Xyz bump)
- NeoGeo Pocket mode: T6W28 (2xSN76489 (stereo) w/ 2x DAC) (Also Z80 compatible) (w/ NGP export)

Nice work :Thumbs up:

VRC7 expansion converted to YM2413 would be pretty cool. Should only need to replace the preset instruments... I might have to take a look at that.

There is going to be one "exemplar" expansion chip implementation done in such a way that all chips are configurable and the internal channels have no first-class status in the code interface, because eventually the successor 0CC-FT has to support this. It is better if I start planning in this project thing where I don't have to worry about incompatibility with vanilla builds (it is guaranteed, it is also left as a practice for you to write a text export filter if you desire compatibility).

KSS export is planned, assuming that is the same thing as SGC, since I could port my 0CC-FT Game Boy-Z80 driver to true Z80.

GG stereo is definitely going to be present, in the same way it is specified for my FT-NSF2GBS draft. There shall also be mixer entries for the left/right channel respectively.

About NGP: It is something I have always wished to do, because right now it is impossible to create two distinct instances of the same channel handler; imagine not just two SN76489's, but two 2A03's plus two AY's with VGM logging support. That has a rather low priority though.

I heard that someone is going to replace VRC7 with OPLL surgically. NSD.Lib also "supports" OPLL directly by requiring custom mapper hardware. That said, despite having removed expansion chip support up to this point, I am not going to just modify the SN76489 parts and call it a new tracker mod. That's nowhere a beautiful thing to do.

I don't mind calling it SnevenTracker by the way : ) ) ) ) thanks

The Github repository is up

.

Sneventracker

Do PC Engine in FT enviroment and I will love you forever

Delek hæitd this

also you should totally do wonderswan and virtual boy kthx

How about PCJr export

Sneven

tracker

Version 0.2.0 is out, see first post for the release page. Click "Log VGM File..." under the Tracker menu, save a VGM somewhere, then the next time you play a song everything will be logged to the VGM file until you stop the player.

The NCx effect allows you to bind the noise channel's pitch to any square channel, not just the third one. For example, NC2 makes the noise channel follow Square 2's pitch for C-# notes; internally, this causes Square 2 to write to the registers of channel 3, and Square 3 to channel 2. Every time this effect is used there will be a small pop in the audio, but judicious use of it can make the pop almost unnoticeable.

The next version will focus on getting all those variants of the SN76489 to work. There is no guarantee on how fast I could deliver new SN7T releases since I still need to work on MGCInts and 0CC-FamiTracker.

The following extra sound chips, and only the following extra sound chips, are planned for SN7T: OPLL (YM2413), OPN2 (YM2612), T6W28, dual SN76489.

What about PCJr. export?

Version 0.2.1 is out because I feel like doing it. Game Gear stereo is supported now, so now it truly has greater expressive power than Deflemask even when tracking at speed 1. (Not that I personally use it since I am partially deaf, but I am sure many of you will, and receive all 1s from me for hardpanning.)

Bug report:

When in low% pulse duty mode via instrument macro (works fine with Vxx), channel 4 does not read the arpeggio/pitch macro information from its assigned NCx channel instrument.

Strange behavior... Tends to fix itself at times when enabling and disabling checkboxes for instrument macro settings and reinitializing the sound engine. Not sure of the culprit!

The SnevenTracker Logo Is Out!!!

Coming Soon

oh man, this is cool

really, not having to futz around with it2vgm is always nice

yes good m8

New version is out, main new features include the NEx noise state reset enable effect and a stereo separation mixer option.

I will annoy everyone until there is a PC Engine tracker, that isn't Deflemask

You're welcome lol

Throwing an idea for icon, since it deserves very own one
64px

32px

what about 16x16?

inb4 new BotB format?

Here ya go, puke ;3

S n' M ;)

I guess KSS is pretty decent but, but also has a standard refresh rate of 60Hz. :(

http://ocremix.org/info/KSS_Format_Specification

Please do not add SnevenTracker itself as a BotB format until it supports more than one sound chip.

I have in fact received 3 or 4 icons including the one above. None of them is usable.

|D( 3|\\|9!|\\|3 7|24(|<3|2

Yes why u go hæit on the HuC6280A

Is very good, trust me I'm a mjengineer

_{@Dezolis: that's the point}
|D( E|\\|L!|\\|E T|TH(|<I|S

https://imgflip.com/i/1fk7bq

The above post

But with extra PC Engine

Great job being smart idiots. Super "good". :) Let's all friend.

needs more wonderswan tbh

inb4 everyone hæits this

xD

I have released a statement concerning SnevenTracker and the future of FamiTracker development. https://github.com/HertzDevil/SnevenTracker/blob/master/STATEMENT.md

"[insert sound chip name] when?"
When any of the following happens:

• The said sound chip is implemented by SnevenTracker;
• Only after SnevenTracker is completed, the sound chip is added to 0CC-FamiTracker's successor, according to the statement above;
• Someone loses patience and forks any branch of FamiTracker at this point. FamiTracker being open-source, anyone can help make this happen, especially the people asking such questions.

I would prefer fixing things before adding new ones, because vanilla FamiTracker already did the opposite with respect to its source code.

[removed]

I'm just haeitin razero for the lulz, no real haeit intended lmao

I think it's great FT is finally evolving into something other than an NES/Famicom tracker but I agree that it has taken way too long for this to happen. I remember seeing convos about such a thing back in 2011 or something???

Perhaps the reason no one really took it so seriously to make such a fork of FT is the effort involved. The builds ipi and Warheart made seemed more like toys to me rather than full-fledged forks, which is evidenced by the lack of NSF export for their new functionalities. I imagine it must take a while to learn all the stuff required to even make a small fork of FT that adds some trivial feature, which would require a lot of dedication and effort, although it might depend on your skill level too (I'm a n00b so it would take a while if I were to do it). Also there might be people who are really interested in doing this but lack the time to do it.

I guess it all depends on how invested someone is into the idea of improving their music tool of choice, and so far you seem to be the only one who has been constant with this. I certainly appreciate all the effort you put into developing all these tools even if I don't really use them (I'm straying away from music more and more every day, but I digress), and I'm sure many other people do as well.

Anyway, I look forward to seeing this madness become real. It would be awesome to finally be able to make music for many systems under a single interface (I've always wanted to fiddle with FM synthesis tools other than the damn VRC7 but I can't be arsed to learn something else kkkkkkkkkkkkkkkkkkkk).

At this point haeitin Razero has become the new BotB meme

If time allows me and I have space on a new SSD (my c: drive ssd is too small rip) for Visual Studio for on my desktop I'll try and implement PC Engine, mednafen myself

you should look from a perspective of someone who can't just open the source code and do magic. your knowledge of famitracker and the nes chip is enormous but it has taken quite some time to acquire. us, lowly humens, just see how much work and dedication it takes and we're pushed off by this, considering it's something done voluntarily and for a community of small numbers. you say - "we should've had SN76489 emulation a decade ago" like it's something that could be done on a free weekend, being relaxed and sipping from a cup of coffee. i'm one of probably many in this community which do not even know how assembly works, which i suspect is crucial in this regard. i know it's crazy to think, but there are actually people who do not get programming in this community as well! i can make some poopy games in oop software like unity or *clears throat* game maker and that does not make me capable of modifying the famitracker source code at all. i took a glance at it once and even though i know the basics, i was clueless. like you mentioned, the key to having more people contribute to famitracker could be the documentation. that will not however change people's views on the whole scale of the thing. you know why people always request the most trivial things that could be done by themselves? because they actually can't. no matter how easy you think it would be to do, they wouldn't share the same opinion. that's why they ask you. it is still rather selfish to request even more from a person who basically revived famitracker from the limbo of the 0.5 beta release, so i understand where you're coming from. that said, i, among others, am very grateful for your work you put into famitracker. you could've kept all your stuff to yourself but you didn't. +tek stfu and contribute to the source code. i'm sorry. i'm not capable.

I agree with every single word of previous post^

I also agree wih every single word of the post that is mentioned in the previous post

Tl;dr I also agree with Plrusek

_{Edit: Why do people hate this comment even when I'm not bitching about something lmao}

Be patient, heh.

The infrastructure of the code is not close to the point to add new features it seems. The first and higher goal is making it easier for others developers to work with even if hertzdevil leaves because life/work/personal interests.

To have a clean code base from which to work with, it seems. He even wants to add what people is requesting because he's interested as a chiptuner.

The statement is not to repeat the same answers in different sites and boards across the internet and consolidate information in one place.

@Razer
Bcuz itz haz becum a maymay =D
_{I actually didn't xD}

I figured

Giv Razero som mor hæit ples //

> "we should've had SN76489 emulation a decade ago" like it's something that could be done on a free weekend, being relaxed and sipping from a cup of coffee.

It is something that could be done on a free weekend, being relaxed, but without sipping from a cup of coffee. (I prefer apple tea.) This is where the cathartic part of the commit history ends. Code that consumes the most effort is exactly where the immediate effects are the least visible.

> there are actually people who do not get programming in this community as well!

Savestate, rainwarrior, Sylveon/Slimeball, null1024, Irrlicht Project, Strobe, ipi, even Delek I would say. There are more amateur chiptuner-programmers than competent chiptuners, and I am not one of the latter.

> i took a glance at [the famitracker source code] once and even though i know the basics, i was clueless.

This is not your fault given the quality of FamiTracker's source; it is also not plausible to blame everyone with zero prior C++ knowledge. People who genuinely want to mod FamiTracker are intimidated by its code structure. This is the whole point of further developing SnevenTracker to a stage where at least the header files are partially self-documenting, and the overall architecture can be deduced from the header files.

Hertz, I have a serious question for you specifically.

Regarding the recent comment I left you on Twitter about your eventually adding YM2612 to SnevenTracker and my willingness to help out as much as possible, even though I can't code. Someone chimed in saying basically I'm part of the problem by having that mentality, and I understand where they are coming from to an extent, but wholeheartedly, I feel like that is a very negative mentality in itself. We don't need more negativity in this community. Any amount is too much, really.
It's not wrong to want something, however, it is entirely up to the creator to decide whether to listen or not. I feel like I fall in the center somewhere. I can't code, but I am still trying to help, and apparently you're eventually going to add the chip I'm most passionate about anyway, so I'm not just bugging you to add something random or meaningless, so does that mean I'm wrong?

If you like or hate this, don't just show it. Explain why you feel that way. If you don't care, or don't want my help, or maybe you even think I'm a joke, or whatever, then just say so.

1) You have no prior C++ knowledge, so it is possible to accuse you only of "not recognizing [your] duties and rights in a modern world of open-source chiptune software". That clause refers to chiptuner-programmers, so that tweet reply serves no useful purpose at all;

2) SnevenTracker is not a project that teaches people how to program in C++. It does not have a duty to teach C++ to its users, so they should not feel helpless due simply to their lack of programming experience. To ease that helplessness, participate in discussions at my bug tracker (or other official means of communication) when the time for OPN2 support is due;

3) OPN2 support is a milestone; it is not "just" a "feature" when it comes to identifying goals of SnevenTracker. An instrument type or pattern effect for the OPN2 is a "feature".

I understand your second point, and I'll keep it in mind.

I also understand, and I do already realise your third point.

About your first point though, I do know, but at the same time, I feel like that is a stretch to a degree. Of course, if I knew how to code, I could help on a code level, or even make my own software, but I also believe that even though that's the case, I still have something useful to contribute to someone that is going to be developing a software for a chip I admit I do have a great deal of understanding towards.

I have come up with ideas for an "OPNTracker" in the past. I drew up plans for a GUI design that is essentially an even easier to use version of Famitracker, with certain existing features being moved around in more logical places, or expanding upon other things. I wrote several of my ideas down, comparing things to Famitracker itself, and moving things from other existing trackers like VGM MM and Deflemask, and expanding upon those also.

Are you familiar with VGM MM or Deflemask? The person came up with the idea and design for special mode in Deflemask was me. I presented the idea to Delek from when I came up with it for that so called OPNTracker, and it works exactly as it's supposed to, rather than the entirely wrong way which VGM MM implemented it. That's why I feel like I am not entirely useless in this sort of thing. I don't want your endeavour into OPN2 implementation to end up as "just another feature incomplete Genesis tracker".

I think that the looks of the FamiTracker GUI is open enough, and thus is the GUI of Sneventracker.


Though I don't think the current style of the FM patch editor is very good, and that's partially due to it not having any visual representations of the separate operators/carriers and being for 2op only.
Such a thing as the FM editor is the only thing that comes to my mind that should be different when talking about GUI.

I never was trying to imply you were part of the problem rai. Simply that those tweets brought up nothing new since it was already addressed in the sneven statement. As if someone cried "hey, what about climate change" when the statement already had a paragraph "Re: climate change".

In any case, and I've never put this so directly before, the world is filled with millions of "idea guys". Idea guys don't accomplish anything.

However, your defle examples does make it seem like you want less to be the designer/idea guy and more of a "Specialty Consultant". Since anyone who really knows OPN2 already knew about Ch3 Special Mode (and possibly how shiru didn't do it right) yet delek seemed to be oblivious until you brought it up. I highly suggest keeping an expert consultant on hand and around the project's issues forum.

> In any case, and I've never put this so directly before, the world is filled with millions of "idea guys". Idea guys don't accomplish anything.

Thanks for that. I am typically very blunt and honest, and I genuinely appreciate getting comments as direct as this. It's short and to the point. I do agree, honestly.

Anyway, you are probably right about why Delek implemented CH3 mode after I bought it up. Though, to be fair, he originally said he would do it like VGM MM did it, until the rest of the Deflemask users agreed that my idea was optimal.

The way I see it, is it's a shame I can't code, because I can pretty much do anything else I want. If I have ideas for a drawing, I can draw it. If I want to animate something frame by frame, I can do it, be it from scratch or existing material. If I want to compose music, or make a cover, I can. These are all things I know how to do, and there is a lot more I can do also.

Coding is the only thing preventing me from making a Genesis tracker of my own, though at the same time, if Hertz is going to make one, and it has the potential to be feature complete compared to older trackers, then besides coding, I should do what I can. As a potential user, it's what I feel is the right thing to do, and it's what I want to do.

Maybe sometime after Hertz does iron out the code, and if for some reason SnevenTracker does not end up feature complete, I may try my hand at understanding and attempting coding again, and *actually* help with it.

SnevenTracker is feature-complete as soon as it supports the OPN2, according to the statement; all "serious" usability concerns will go to the successor of 0CC-FamiTracker. I already have my own plans for implementing the OPN2 in SnevenTracker. Again, you are anyone is welcome to contribute ideas when the time is due.

That's totally fine. I don't mind tossing some of the ideas I came up with concerning usability going towards 0CC FT.

About the OPN2 for SnT (yes, I attempted to abbreviate SnevenTracker), right off the bat, I hope you go for a VGM Music Maker style FM editor. That's pretty much the best thing about that tracker tbh.

In any case, I'll throw my ideas your way once OPN2 implementation begins.

Out of curiosity, will you be including support for PCM or HBlank manipulation

for the SN chip?

Haven't seen any PSG sample abilities in a tracker before, so that's interesting to make SnT have a really strong point if that's possible

And about the CPU going all nutshack for the SN76489 is fine by me, because who is going to make SMS games anyways these days?

The best way to help famitracker, or 0ccft is using it daily and crashing it often to get it polished faster

try your best, or do your worst XD

i wish i could double-liek that comment, os. :P

"the CPU going all nutshack for the SN76489" Anything that attempts to stream samples in real-time is going to.

While the refactoring in SN7T (the correct abbreviation) should make those instruments easier to implement, they are not in the scope of SN7T.

> At least Raijin will be happy finally

Not necessarily. I still want to push the Genesis sound to its absolute limit, that includes the PSG, though I can live without PSG PCM and HBlank Manipulation for the time being.

If this tracker ends up not including things current trackers also see fit to leave out, like an easy to use/understand FM editor similar to VGM MM, PCM implementation which doesn't treat copies of a sample as a new sample, and a robust sample editor to go with it, Multi PCM, CH3 Special mode and CSM Voice mode, Timer A/B control, proper tempo support (an 'integral mode' which disables the speed setting, then can be used to change the tempo, which only selects integral tempo values, if it can be done. Actually, I'd like to hear opinions about this), and probably some other things I am forgetting. That's what I meant by feature complete.

Don't get me wrong though, either way, I'm still going to use it/give ideas/report bugs. Whether I stick with it though, I can't say yet. Hertz is doing fine work with these trackers.

Is there any use for the timers outside of using TimerA for CSM?

Frankly speaking, I'm not really certain why an SN7 tracker would be evolving into another tracker with a bigger main chip; such as the OPN2...

OPLL is something that is in addition to the main SN7 and makes a lot of sense; also other sound chips based on the SN7.

Delek has not given up on his OPN2 interface and I've made posts in regard to the function of CSM phoneme mode on his forum via debugging/disassembly/VGM reverse-engineering. He has all the discrepancies via OPN2 and OPNA.

Regarding KSS, it's a shame there is no PAL or custom refresh mode possible since it defaults to 60Hz.

~~~~~~~~~~~~~

Raijin: Your best way to possibly get this information to Delek is to compose a VGM with DefleMask, disassemble with vgm2txt, hexedit the VGM, insert lines with direct register writes of desired affect into the VGM, etc. :) Maybe even assemble into a binary with DeadFish's VGM2BIN... Exodus (the emulator) emulates all of the functions you desire and you can watch the registers in real time to see if your code is affecting properly.

:)

Yeah. I asked around awhile back about the sound effects in Gradius 2. They seem to be using the timers for sound effects, and the OPN2 has it too. Apparently, it effectively doubles the BPM to 1800 or rather the clock rate to 120Hz, or something like that, basically. It's kind of like the NES' hardware sweeps, I guess.

> proper tempo support (an 'integral mode' which disables the speed setting, then can be used to change the tempo, which only selects integral tempo values, if it can be done. Actually, I'd like to hear opinions about this)

In 0CC-FamiTracker you probably can, by disabling the tempo instead and then changing the refresh rate. If I port 0.5.0 beta's refresh interval setting, then a lot more BPM values can be attained while keeping 6 ticks per row. You still have only one base BPM value though, other values have to be accessed with speed or groove settings.

The VGM format assumes the refresh rate of 44.1 kHz, so time scaling will only lead to negligible timing errors; thus the refresh rate can be used to control the tempo even in real-time, but that might not be supported by other export formats, including the actual sound driver on the target platform. FT-NSF2GBS actually supports this, because the GBS format will emulate the timer interrupt; on the other hand VGMs do not require a timer at all.

In general all timing-sensitive features require an actual assembly driver to make those features "credible" in a tracker, otherwise the tracker will only become closer to "simulation" than "emulation".

Throwing my perspective/few cents in:

I wouldn't mind working on FamiTracker code or any of its derivatives (I have some C++ experience), except the code is dependent on a whole bunch of Windows libraries (MSVC, MFC, DirectX) and my development tools/workflow are all Linux-based. And I think there were at least two attempts to port FamiTracker to something cross-platform which I think were eventually abandoned? Also, from skimming through some of the FT source code a few times, I agree, it does NOT look easy to work with.

I'd love to have a real port/rework/alternative of FT or some derivative that works natively without using Wine that I could actually work with, and I would totally contribute to such a project if it existed. I've also had some thoughts about remaking FT or something similar from scratch but I haven't really had the experience of making a full-blown application, nor do I think I'd have the time for making something like that.

The next easiest port would be to take SnevenTracker and replace the SN7 with the 6560/6561 (VIC). The VIC (NTSC-6560/PAL-6561) is arguably the easiest sound chip to understand.

https://www.mdawson.net/vic20chrome/display/mos_6560_6561_vic.pdf

There are only four and a half 8-bit audio registers. :)

@HertzDevil I'm glad to know that it's possible at least. I hope someday to see such a thing fleshed out more. If the Genesis had an actual sound format, it would certainly be useful for hardware playback.

Nice. I'm looking forward to explore SnevenTracker and see how it will go with the OPN2 implemented. :3

I actually wonder how you're going to implement the instrument editor for OPN2 (mainly the UI design)

By the way, before I forget, keep in mind the SN76489 has 10 octaves. Very useful for achieving all of the noise frequencies, and another thing no tracker has yet to implement.

edit: nvm

Whaat? what is SN76489?

Sky Yoshi

The SN76489 Digital Complex Sound Generator (DCSG) is a TTL-compatible programmable sound generator chip from Texas Instruments. It contains

3 square wave tone generators.
A wide range of frequencies.
16 different volume levels.
1 noise generator.
2 types (white noise and periodic).
3 different frequencies.
16 different volume levels.

@ SkyYoshi

http://lmgtfy.com/?iie=1&q=what+is+SN76489%3F

A quick demo of the new NE1 effect in case people don't understand it.
https://www.dropbox.com/s/zu6urxi2o4gv562/SnevenNE1Effect.snm?dl=1

To clarify exactly what I meant when I said 10 octaves, I just meant it would be nice if you transposed the frequency table down 1 octave (if I am even wording that right). Basically so C-3 will be C-2 and so on, so that key presses can be done for the highest frequencies, instead of using pitch macros or Pxx. It's just an ease of use thing, I guess. Also, if you can, I'd like to see the hold function (the '&&' effect from FT's current beta) if possible. It would be nice if it would carry over to later chips that get added too.

Anyway, I made a 32x32 icon. I have 2 versions, here

and here

Do you think it is good enough to use? If so, go ahead and use whichever one you like more.

Last but not least, the Legend must live on.

Edit: Sorry, almost forgot. I still have my mocks for the so called OPNTracker I mentioned before. If you can get some ideas out of this for SN7T's OPN2 support (or even 0ccFT itself) by all means, use it.

https://www.dropbox.com/s/c4z9l442xn1l9bj/genesistracker.png?dl=0

https://www.dropbox.com/s/7lnwyn8ag7qcd0c/genesistracker_editor.png?dl=0

Another Edit: Here is my notes as well.

https://www.dropbox.com/s/mf2c15s0rxgi5tl/OPN%20Tracker%20Notes.txt?dl=0

I think you can get some use out of this. It explains some of the ideas I drew in the mocks, some of my own additions and rearranges and such, and some differences with VGM MM and Deflemask, and things they do that SnevenTracker should not do. Keep in mind though, that some things do refer to the fact that it was going to be it's own tracker.