Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
as I've already said once before, it needs to be left in because it handles things in a very different way. Depending on how things are set up, it can change quite a bit in the old files.
[color=#C08080]EDIT: Splitted from the request list, after [url=http://famitracker.shoodot.net/forum/posts.php?id=292&pid=1707#1707]this post.
- jsr
Wow, that was fast! And it works great, too. This is [i]much[/i] better. I know I'm not supposed to use WIP builds for actual composition, but I'm gonna be a naughty boy and do it anyway 'cause this is just that useful. Will you be adding this to the NSF export soon?
As for the compatibility mode question, I wouldn't mind just doing without, but that's easy for me to say since I don't have terribly many FTMs in the first place...
[quote=Cheez]as I've already said once before, it needs to be left in because it handles things in a very different way. Depending on how things are set up, it can change quite a bit in the old files.[/quote]
I think breaking old FTMs isn't that big a deal because I assume most people will turn their music into NSFs after they're done composing it, so it'd mostly affect people who are working on something and then upgrade while they're working on it. In that case, if they'd rather not rework their FTM, they can simply use the old version for their project until they're ready to upgrade.
Of course, we shouldn't break backwards compatibility gratuitously, but in this case I think it's justifiable enough.
Can't the old Exx effect be used to do it either the old way or the new way, so that people who prefer the old way can keep using that without having to sacrifice expansion chip support? Anyway, I'm leaving the request in the list until it's been settled.
While we're at it, I'd like to request a major change to how Famitracker works too! Personally, I find it pretty annoying that instrument settings override effects entered in the pattern editor - shouldn't it be the other way around? For example, if I have an instrument that uses a certain duty cycle, and I might want it to use another one at a certain point, I want to be able to use the Vxx effect. When I want it to go back to whatever duty cycle setting the instrument had, I could enter "Vxx" in the effect column to stop overriding its settings. Of course, it would be best if this could be made an option rather than a definite change.
This will all require a lot more work than the first request I made, about row highlightning, though! And it's also something I consider much less important right now - making songs in 6/8 is a pain in the current (and all previous) versions - instruments overriding effects I can live with for the moment.
[quote=Dafydd]Can't the old Exx effect be used to do it either the old way or the new way, so that people who prefer the old way can keep using that without having to sacrifice expansion chip support?[/quote]
Who exactly is going to both prefer the old way and use an expansion chip? The expansion chips have only been in WIP builds, which are not supposed to be used for composing in the first place (although some people do it anyway, including me now). Unless you're going to end up with a compatibility problem, there's no reason to prefer the old way. So the only people who are really affected in that way are people who were using the WIP builds to compose music, and, well, I think having to fiddle with your modules to deal with little compatibility issues from version to version comes with the territory. That's why they're called WIPs, after all.
[quote=Dafydd]Personally, I find it pretty annoying that instrument settings override effects entered in the pattern editor - shouldn't it be the other way around? For example, if I have an instrument that uses a certain duty cycle, and I might want it to use another one at a certain point, I want to be able to use the Vxx effect. When I want it to go back to whatever duty cycle setting the instrument had, I could enter "Vxx" in the effect column to stop overriding its settings. Of course, it would be best if this could be made an option rather than a definite change.[/quote]
I dunno. I see the logic of your argument, but I usually use blank duty cycle envelopes in the first place, preferring to use Vxx instead, unless I actually need an envelope, which for me isn't terribly often, so it doesn't really bother me to have to use a separate instrument. The way it works now is also simpler: nobody has to figure out, "Oh crap, what's that command to switch back to the instrument's duty cycle again?"
Making it optional has disadvantages, too. Different FTMs will appear to behave differently, which may be difficult for some users to understand: "Why does Joe's module behave this way and my module behave that way?". It also makes it more difficult to maintain the source code. Finally, it can lead to a slippery slope: why stop there? Why not add, say, an option to have the volume column and effects column behave more like MOD/XM/S3M/IT, where the tracker "forgets" the setting after each row and resets to the default? Although I might prefer for the tracker to behave that way, I think adding it in as an option would probably be more trouble than it's really worth, for the same reasons. So I think, on the whole, allowing module-specific preferences is a Bad Thing.
[quote=furrykef]Who exactly is going to both prefer the old way and use an expansion chip?[/quote]
Not me, I never use the volume column anyway. I thought there were others and tried to come up with a solution.
[quote=furrykef]I dunno. I see the logic of your argument, but I usually use blank duty cycle envelopes in the first place, preferring to use Vxx instead, unless I actually need an envelope, which for me isn't terribly often, so it doesn't really bother me to have to use a separate instrument.[/quote]
[quote=furrykef]Wow, that was fast! And it works great, too. This is [i]much[/i] better. I know I'm not supposed to use WIP builds for actual composition, but I'm gonna be a naughty boy and do it anyway 'cause this is just that useful. Will you be adding this to the NSF export soon?
As for the compatibility mode question, I wouldn't mind just doing without, but that's easy for me to say since I don't have terribly many FTMs in the first place...
[quote=Cheez]as I've already said once before, it needs to be left in because it handles things in a very different way. Depending on how things are set up, it can change quite a bit in the old files.[/quote]
I think breaking old FTMs isn't that big a deal because I assume most people will turn their music into NSFs after they're done composing it, so it'd mostly affect people who are working on something and then upgrade while they're working on it. In that case, if they'd rather not rework their FTM, they can simply use the old version for their project until they're ready to upgrade.
Of course, we shouldn't break backwards compatibility gratuitously, but in this case I think it's justifiable enough.
- Kef
[/quote]Most of my stuff isn't actually DONE, and that which i'm finishing or have finished with the addition of the expansion chip now sounds different because of it.
Well, as I said, you should expect that sort of thing when you use WIPs to compose music, and you should be using the stable version of the tracker for tracks that don't need the WIP's features, which would allow you to simply finish them with that version of the tracker. After all, there's no problem having two versions of FamiTracker on your computer.
Now, I don't want to say that the right thing to do is to do the thing that messes up all your work, but, again, these are WIP builds for a reason. They're not meant to be full releases and shouldn't be treated as such. If you don't want jsr to do things like change features around between WIPs, then the only real alternative is not to have WIPs, because allowing jsr to do things like that is the whole [i]point[/i] of releasing them as WIPs. If you're not prepared to deal with that, you shouldn't be using them.
You're not saying anything right. You want me to use a version that DOESN'T have the very important feature I need (VRC6), but you also seem to be saying that there's no hope for the future version to work because apparently in your mind the WIP is never going to change.
What is the entire point of this request list if the damn requests, no matter how reasonable, won't get done?
Ooohh, yeah. That's annoying as hell. Up on the list you go.
You could rid yourself of this problem by just using the + and - keys on the keyboard and never clicking on the + and - buttons below the pattern editor. But I agree it's annoying. I hope the request title is ok with you.
(Ugh. The damn quote feature on this forum is totally broken. Somebody really needs to fix that...)
[quote=Cheez]You're not saying anything right. You want me to use a version that DOESN'T have the very important feature I need (VRC6)[/quote]
As for that, I'll quote jsr's own words about using WIPs (emphasis mine):
[quote=jsr]Here I'll post about work in progress updates. That means some things will be broken or incomplete, so [b]these updates are for testing only[/b].
[...]
[b]Please get the official version for composing.[/b][/quote]
It's like he's saying, "If you use this to compose actual music, you will get struck by lightning," and now you're surprised to get struck by lightning. Why?
My point is, if you had been following jsr's advice, you would not be in the situation you're in, so you should have been prepared to deal with the consequences of ignoring his advice. I myself am using the WIP to make music, but I'm prepared for things to happen. It'd really suck if the WIP build ate my FTM and made it unrecoverable, but other than that, I pretty much don't mind anything that could happen; I'd just edit my project to deal with it.
[quote]but you also seem to be saying that there's no hope for the future version to work because apparently in your mind the WIP is never going to change.
What is the entire point of this request list if the damn requests, no matter how reasonable, won't get done?[/quote]
Your request is reasonable in the sense that it's not clear whether or not a compatibility mode is the "right" way to do things -- although I myself am leaning more towards the omission of a compatibility mode for the same reasons I've explained regarding other features. But where I think you're getting a bit unreasonable is apparently assuming that jsr has some sort of responsibility not to break compatibility between WIPs, when the whole reason the WIP system exists is so that he could do exactly that sort of thing. WIP means that jsr could, say, invent some new commands in one release and completely rearrange or remove the added commands in the next release -- and if doing breaks your song, too bad, because you weren't supposed to be using the WIP to compose real music anyway. That's what WIP is all about.
To sum up my thoughts: Is it unreasonable to request a compatibility mode? Of course not. But should jsr implement it just because you got yourself into a situation that you shouldn't have gotten into in the first place? No, that wouldn't be the right reason.
Now, if you made the argument that people who are using the [i]official[/i] 0.2.7 build of FamiTracker would get in the same sort of situation, then you would have a point, because users [i]are[/i] supposed to use that build. But so far I don't really see why it'd be a problem for somebody using 0.2.7 who wants the old behavior to simply keep using 0.2.7 for that project, since they probably won't really need the new features in 0.2.8 anyway.
[quote=Dafydd]Personally, I find the old way the volume column works to be pretty useful for noise and especially the triangle channel[/quote]
I'm confused. You can't even enter anything in the volume column in the triangle channel, and it'd make no difference if even you could because the envelope would still behave the same way, since the channel is either on or off and a value of 0 (or less than 0) gets rounded up to 1.
Your argument makes sense for the noise channel, but I think the new behavior is perfectly useful for that as well. (As for my own compositions, I'm leaning away from using the volume column much at all for the noise channel, no matter which behavior is used. If I want a louder snare and quieter hi hats, it's much better not to have to put volume changes everywhere... with other channels I don't have the same problem because I don't change instruments so much, and when I do I often want them the same volume anyway.)
You realize that WIPs aren't WIPs forever, and they eventually become new versions, so if a song is BROKEN by these WIPs it should be POINTED OUT so that the NEW VERSION doesn't SCREW ME OVER. Right? You just don't seem to get that. If you don't use the WIP, you can't find out if anything's being broken, and it can't be fixed.
As for your comment about the triangle channel, don't forget that the sound cuts out sooner the old way. 0s are 0s.
[quote=Cheez]You realize that WIPs aren't WIPs forever, and they eventually become new versions, so if a song is BROKEN by these WIPs it should be POINTED OUT so that the NEW VERSION doesn't SCREW ME OVER. Right?[/quote]
Calm down. There's no need to talk that way. I'm not even a FamiTracker dev, so I'm not responsible for your quandary in the first place...
Anyway, my point is, in your case, it doesn't seem as if you'd be screwed over if you weren't doing something you shouldn't be doing. That's why I had an issue with it. But in any case, you'll only get screwed over if you upgrade. So, why not just use a new version for new tracks and an old version for old tracks? The main thing you gotta watch out for is that modules saved with the current version will crash when loaded in the old version, so you have to be sure to use the right version...
By the way, have you looked into how hard it'll actually be to fix your songs? I don't even use very many instrument envelopes in mine. Fixing my current project was pretty much click, click, boom. Maybe you use a ton of 'em, I dunno, but I suspect it may not be as bad as you think it is. Shoot, I could fix them myself for you if it bothers you that much.
[quote=Cheez]As for your comment about the triangle channel, don't forget that the sound cuts out sooner the old way. 0s are 0s.[/quote]
I don't understand. As I said, you can't set the volume of the triangle channel in the first place, and even if you could, an envelope of 1 1 1 1 1 0 played at volume 1 would sound exactly the same as if it were 15 15 15 15 15 0 at a volume of F. There are no 0s until it actually hits 0 in the envelope. Even in the square channels, FamiTracker always rounds up to 1; it never hits 0 except when you actually type in the number 0. The old way will hit 1 much sooner, but it will hit 0 at the same time as the new way.
[quote=Cheez]1. Seeing as you didn't bother to read what I said, could you just stop responding altogether?[/quote]
I'm sorry, but that was uncalled for. This has been a long and exhausting conversation for both of us and I think it's perfectly understandable if I missed or forgot something you said. But, re-reading the conversation, I still can't find anywhere you addressed my point. So I don't see any way in which I've indicated not reading what you've said.
Besides, I offered to fix your problem for you. Is that any way to treat somebody who is offering to help you?
[quote=Cheez]Doesn't explain why instruments appear to cut out sooner with a lower volume. A 1 isn't silence.[/quote]
Can you post an FTM that behaves differently in the triangle channel between the old version and the new one, or tell me how to make one? I can't produce one.
Moreover, the volume scaling algorithm wouldn't explain it either (unless the implemenation is buggy, which I don't think it is) because, as I've been trying to say, there [i]is[/i] no volume scaling in the triangle channel. When the channel is at maximum volume (as the triangle channel always is), scaling doesn't apply at all, so the algorithm used is entirely irrelevant.
But I bet you can't produce such a thing with the square channels either. The note may appear to cut off sooner with the old method, but it'd be an illusion.
This is [i]much[/i] better. I know I'm not supposed to use WIP builds for actual composition, but I'm gonna be a naughty boy and do it anyway 'cause this is just that useful. Will you be adding this to the NSF export soon?