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.
You know, you're right, and I'm wrong. Disregard what I just said about this. I should make it a habit not to argue with you because this is how it always ends.
I was going to say "use Dxx!" but I imagine that's what you just found
Ehh as for backwards compatibility by having two different volume controls (subtractive and scaled), that sounds a bad idea to me. It'd be clunky, and would only be useful in the short term - subtractive doesn't give a practical advantage I know of. I really don't think changing the way volume works is going to mess up projects too bad anyway, and if it does, they're not beyond repair.
That said, having two (of the same) volume controls is actually useful - say you're writing a drum part and you want to change the volume on the fly for note velocities, but you also want to add a fade-out (or maybe just want to set an overall channel volume). This is one of the comforts I'm used to with general MIDI (which actually has three; note velocity, volume and expression). It's very useful/practical. I can manage with one volume control though.
Well... that goes back to the whole "you play with fire, you get burned" aspect of using WIPs...
But what do you mean they don't save? How could you have VRC6 modules in the first place if the tracker couldn't save them? I'm confused.
Anyway, as I said, I'm offering to fix your modules for you. But, again, have you even had a look at how hard it would be to do it yourself? (And you wouldn't have to fix them all at once, of course... only when you start to work on a particular module again. It seems much less bothersome to do it that way even though it's the same amount of work.) Or are you merely assuming it'll be a whole ton of work?
How hard can it be to understand? VRC6/7 was supported. Ish. VRC6 was barely usable, and the part that would have appeared in the window didn't. And, if you had ever been paying attention to much at all, you would have known that the old versions did NOT have the ability to load/save VRC6 ftms properly.
And no. I see no reason to "fix" them by making them even more cluttered.
(To forum mods: I propose splitting this argument to another thread.)
By the way, I'd like to make a correction to what I said: apparently the WIP build does not round 0 up to 1 when scaling envelopes, but the old version did. So the WIP build actually cuts off the instrument sooner than the old build does. I feel a bit silly now, but apparently all of us were wrong about that. For what it's worth, I think I prefer rounding up to 1, but I'm not 100% sure.
Anyway, Cheez, you still haven't answered if you've even bothered to look at how hard converting your FTMs would actually be. If you haven't done so, then, to be honest, you have no right to complain. So, have you looked into it? And, if so, what have you found? What are the precise repercussions of the new way of doing things -- something more concrete than "I'll have to redo a bunch of stuff"? To be honest, I have a hunch that much of what is bad about this whole change is only in your mind... if I'm wrong, well, you need to prove that.
Cheez wrote:
How hard can it be to understand? VRC6/7 was supported. Ish. VRC6 was barely usable, and the part that would have appeared in the window didn't.
So, it sounds like you're working with modules that have always been designed with VRC6 support in mind, but you have not actually been able to add such VRC6 support yet because of the WIP status of the whole thing?
To be honest, I think the circumstances that keep you from upgrading while using an old version for old modules are very specific. How many other users are going to be in exactly the same situation, and how many of those users are really going to mind?
Cheez wrote:
And, if you had ever been paying attention to much at all, you would have known that the old versions did NOT have the ability to load/save VRC6 ftms properly.
Why should I have known that? It wasn't said in this thread (at least I don't think so), and I generally don't follow the status of WIPs or expansion chip support. Your remarks of "if you had been paying attention", etc. are rather unnecessary. Moreover, I wish you would stop treating me like some big antagonist. I can't see anything I've done wrong in this thread, but you've shown constant impatience and occasional condescension. What's the deal? I get the feeling that you're using me as a target to vent your frustration.
Cheez wrote:
And no. I see no reason to "fix" them by making them even more cluttered.
How exactly would your modules become more cluttered? I can't imagine the old method providing any advantages (beyond compatibility), and that includes the advantage of making songs less cluttered in some way. I actually find the old way more likely to produce clutter because you need to create extra instruments to scale envelopes properly, when now all you have to do is just use the volume column.
yeah, sounds like a good idea. actually, i remember virt requesting this in the past.
furrykef wrote:
For what it's worth, I think I prefer rounding up to 1, but I'm not 100% sure.
this was another thing virt originally requested, but since volume is now scaled, a volume value of 1 in an instrument won't (shouldn't?) change to 0 until the a volume of 0 is set in the patterns/arrangement. ergo, rounding up is no longer needed. err, at least i think that's how it's done - would make sense to me.
this was another thing virt originally requested, but since volume is now scaled, a volume value of 1 in an instrument won't (shouldn't?) change to 0 until the a volume of 0 is set in the patterns/arrangement. ergo, rounding up is no longer needed. err, at least i think that's how it's done - would make sense to me.
No, what happens is you can get numbers between 0 and 1, and those are currently truncated to 0. Consider what happens when you have an envelope of "1" (yep, just "1") and you play it at volume 1: the result you get is 1*1/15 = 0.067 (approx.), which truncates to 0.
By the way, I'd like to make a correction to what I said: apparently the WIP build does not round 0 up to 1 when scaling envelopes, but the old version did. So the WIP build actually cuts off the instrument sooner than the old build does.
Then explain how the "loud" length of one of my instruments doubled in the new version.
furrykef wrote:
Anyway, Cheez, you still haven't answered if you've even bothered to look at how hard converting your FTMs would actually be. If you haven't done so, then, to be honest, you have no right to complain. So, have you looked into it? And, if so, what have you found? What are the precise repercussions of the new way of doing things -- something more concrete than "I'll have to redo a bunch of stuff"? To be honest, I have a hunch that much of what is bad about this whole change is only in your mind... if I'm wrong, well, you need to prove that.
Why are you so against having a feature? You're not the one programming the damn thing, so you have no reason to fight it. We're also missing a "proper" frequency range for pitch slides and other related things. Are you going to fight against that too?
furrykef wrote:
So, it sounds like you're working with modules that have always been designed with VRC6 support in mind
Since 0.2.6 actually. It was one of the first things I worked on, but then found I couldn't reasonably do it without waiting for expansion support.
furrykef wrote:
To be honest, I think the circumstances that keep you from upgrading while using an old version for old modules are very specific. How many other users are going to be in exactly the same situation, and how many of those users are really going to mind?
Assuming you're putting negativity into that paragraph like all your others, what reason is that not to add a useful feature?
furrykef wrote:
Why should I have known that? It wasn't said in this thread (at least I don't think so), and I generally don't follow the status of WIPs or expansion chip support.
Which is why I have to bring it up. If it were as simple as sticking with something that had everything I needed, then I wouldn't have had to mention it, hm?
furrykef wrote:
Moreover, I wish you would stop treating me like some big antagonist. I can't see anything I've done wrong in this thread, but you've shown constant impatience and occasional condescension. What's the deal? I get the feeling that you're using me as a target to vent your frustration.
fighting with me over what should and shouldn't be a feature is a pretty big wrong, you know...
furrykef wrote:
I actually find the old way more likely to produce clutter because you need to create extra instruments to scale envelopes properly, when now all you have to do is just use the volume column.
And you're forgetting that not everyone does things the way you do them, whatever it is you're doing. I already pretty much had it so I only had to use the one instrument and one volume envelope. Now I'll apparently have to either use more or do it the stupid way you suggest and flood the volume column for the entire song when I'm not supposed to need to.
Weird Cheez, I'm confused as to how the scaled volume would cause so many problems for you. Like furrykef has said, I really would expect it to cut down on the amount of instruments you need. Apologies if you've answered this already, but what is stopping you from going through your FTM(s) and updating it? Just trying to understand your situation.
furrykef wrote:
No, what happens is you can get numbers between 0 and 1, and those are currently truncated to 0. Consider what happens when you have an envelope of "1" (yep, just "1" and you play it at volume 1: the result you get is 1*1/15 = 0.067 (approx.), which truncates to 0.
Oh yeah, I suppose we do still need rounding up even with scaled volume. I wasn't thinking in terms of numbers in between numbers, just in terms of 0 - 16, so I guess I wasn't thinking of it as rounding up, but it's definitely what should happen. That should happen with all the numbers though. Like 10 is still 10 even at 9.1, etc. The only number that wouldn't need it is 16 because that can never be fractional.
I hope I am getting my head around this now o_O I think the main difference is rounding up now would be more an integral functionality of how the volume control works, rather than as a slapped on "fail-safe" like it was before.
Then explain how the "loud" length of one of my instruments doubled in the new version.
The "loud" length is longer in the new version, but the instrument will hit 0 sooner. The issue of scaling vs. subtracting and the issue of rounding 0 to 1 are completely separate.
Here's an illustration of what I mean. Let's suppose we have an envelope of 5 4 3 2 1 0, and we play it at volume D. With the old method, this results in an envelope of 2 1 1 1 1 0. With the new method, it results in an envelope of 4 3 2 1 0 -- hitting 1 much later, but hitting 0 a bit sooner, because 0 is no longer rounded up.
Cheez wrote:
Why are you so against having a feature? You're not the one programming the damn thing, so you have no reason to fight it.
I already explained why I don't really like the idea of having module-specific 'switches' for personal preferences early on in the thread. I was talking about a different feature at the time, but the same arguments apply. Here's what I said again:
furrykef wrote:
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.
But I'm not really "fighting it" so much as trying (and, admittedly, not always succeeding) to point out what I perceive as flaws in your reasoning. I think this is where we're having problems; you seem to think I'm opposed to you in some way, when I'm really just trying to get at the heart of the issue of figuring out if it really is such a bad thing to let jsr simply drop the old way of doing things.
If it helps, just consider me as playing devil's advocate. Besides, how do you know I won't become a FamiTracker dev someday and have to deal with maintenance issues caused by having a compatibility mode?
Cheez wrote:
We're also missing a "proper" frequency range for pitch slides and other related things. Are you going to fight against that too?
*shrug* I'd love proper pitch slides as much as anybody. I think there's a technical reason that that we can't have them, though. I'm not opposed to advancing FamiTracker as a whole; didn't I suggest the feature that got us into this mess?
Cheez wrote:
Assuming you're putting negativity into that paragraph like all your others, what reason is that not to add a useful feature?
"Adding a useful feature" takes jsr's time away from other things and it makes the code harder to maintain. So we need to get an idea of how useful the actual feature is -- and by that I mean considering how useful it is to most people, not just one person.
Cheez wrote:
And you're forgetting that not everyone does things the way you do them, whatever it is you're doing. I already pretty much had it so I only had to use the one instrument and one volume envelope. Now I'll apparently have to either use more or do it the stupid way you suggest and flood the volume column for the entire song when I'm not supposed to need to.
See, this is all I wanted: a more concrete response that actually demonstrates why this is a problem beyond "It will break everything!". May I see your FTM so I can understand the problem better?
Forget the FTM(s) right now. What I want you to get is that there were two different ways of pitchsliding back in my FT2 days, the difference between the two being amiga and linear frequency tables. Can famitracker not go the same direction with volume control? Make it a per-ftm thing, or even a per instrument thing. I see no reason to have to rewrite and add things to previous versions' FTMs because of a permanent change in how things work.
Forget the FTM(s) right now. What I want you to get is that there were two different ways of pitchsliding back in my FT2 days, the difference between the two being amiga and linear frequency tables.
How many people compose with Amiga frequency slides today? I know I've never touched the option. These days it's rather useless, an accident of history. But trackers generally continue to support it because they're used to play music as well as listen to it, because with those trackers, the working format is the same as the output format. But with FamiTracker, that's not the case: the working format is FTM and the output format is NSF. You can distribute the music itself in FTM format, of course, but I think the main idea is to be able to make NSFs.
I just want the FTM because I still can't comprehend why it's such a big deal for your module. I don't see where this problem of "I used to need only one instrument and now I need more" is coming from. If you just say "forget the FTM" then I have no proof that your problem is in fact really a problem, and neither does jsr. You ought to establish that there really is a problem before we consider adding compatibility modes, right?
Dafydd wrote:
I guess so. I never thought it necessary to have more presets - their purpose seems to be more of a learning and testing thing than something you'd actually use much once you learn how to make your own instruments. I know they were a great help for me to understand how the macros worked, but I don't really use them anymore. At all.
I use 'em. They're often good for quickly getting the sort of sound I want and then I'll just tweak it as necessary. If I don't find it necessary, then I'll just leave it alone.
