Author Topic: Huzak - Yet another music driver  (Read 14018 times)

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: Huzak - Yet another music driver
« Reply #60 on: January 11, 2017, 12:09:02 AM »
It might also be useful for sound effects, when someone starts bothering to use Deflemask for that.



[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

elmer

  • Hero Member
  • *****
  • Posts: 2154
Re: Huzak - Yet another music driver
« Reply #61 on: January 11, 2017, 04:43:29 AM »
OK, thanks guys, those are useful answers, and I'll ask more questions later on, but first, perhaps I should go back and explain what my problem is ...

It's all a case of exactly *when* you change the row timing, and the interaction of that new timing with some of the effects commands, and especially, how to process things efficiently so that we're not paying an undue cost for something that rarely (if ever) happens.

The issue that I have, is that you can change the row speed, and that it effects the length of the exact row that you issue the new speed on.

So if you're on the 1st row in a pattern, and you change Speed1 (with effect 09xx), then that speed is used (or it appears to be used, to me) as the duration of that row.

You can set that effect *anywhere* in the row, which means that the driver will process some, or all, of the other channel's notes/effects before the row speed is changed.

The problem is that some effects commands (particularly Note Delay and Note Cut) need to know what the exact row speed *will* be, and they need to know it as soon as they're encountered during the notes/effects for that row.

Deflemask can get around this chicken-and-egg problem just by scanning the row first and setting the new row speed (if there is one) before processing any of the other notes/effects on the row.

We can't do that (practically) in a sound driver.

I need to decide how to work around that problem.

BTW ... the issue here is really with the "Note Delay" effect.

Is that effect even useful anymore, now that you can achieve so much with the Envelope/Arpeggio/Wave Macros? (Which AFAIK eliminate the need for the weird 1:7 timings that I've seen used).

FYI ... just ignoring that *one* effect would make all of my problems go away (the Note Cut *can* be processed a little-less efficiently, but still work).



One solution is to automatically create a separate invisible "timing" channel, and move all of the changes in row speed into that channel while converting the .dmf file.

It's a bit of a PITA, and will waste some memory for songs that don't change their timings, and cost a *little* bit of extra processing time ... but it has the advantage that it will work reliably, and keep the what-you-see-is-what-you-hear advantage that Deflemask offers.



The alternate solution, is to strip out the timing info, and have the driver use its own timing, for example, the 8 different row speeds that I suggested earlier.

The advantage here is that it is practically free to process, takes almost no extra memory, it gives you very fine-grained control over the tempo for a song, and that it makes changing the tempo *inside-the-game* very, very easy (for boss-rush tracks when the tune gets faster and faster).

But ... even though those 8 speed-settings could be initialized from the settings in the .dmf file when it is converted, you would lose the flexibility to change the row-speed at *any* time within the song data itself, and so you'd lose a bit of the what-you-see-is-what-you-hear advantage.



Now, as a programmer, I find the 2nd solution to be the most-elegant and efficient ... but I'm not the guy that makes the music.

What do you guys feel? Which alternative sounds better to you, and/or can you just live without "Note Delay"?  :-k

Or ... perhaps I'll just take a very long walk and *possibly* figure out a way to work around the problem.  ](*,)

Gredler

  • Guest
Re: Huzak - Yet another music driver
« Reply #62 on: January 11, 2017, 05:21:28 AM »
So, where is this at?

DK I gotta request you to improve your bedside manner :P I think you mean "Is there an ETA on when the driver will be usable?" or something along the lines of a timetable if we should be trying to recruit a deflemask sound person now or is it far off to where it'd be too early to do that now (he and I have not talked, but I am assuming this is the case as we currently don't have any sound person who's committed to help)

If you're really itching to get finished on Catastrophy, then IMHO your best option is to try to get Arkhan to do the tunes/sfx in Squirrel (running in the vblank), and then see if he can figure out how you can play those extra samples that you want.

The last time DK and I spoke about Catastrophy we both agreed that we hope to finish at one point this year. Enthusiastically our prospects seemed more likely because of your help with making HuC more efficient and stable; and now this potential new pool of musicians to possibly recruit from would be the deal sealer that we have the ability to finish everything we want to do. As awesome as it would be to finish Catastrophy this year we do not have some obligation to do so (no kick starter/people waiting/funding/etc), and I sincerely doubt that this music driver would be the bottle neck - my pension for lagging and re-working my crappy art to look acceptable will much more likely delay the project than the lack of a musician; like you said if we needed this thing tomorrow I am sure Arkhan would be a champion and help us out.

To be honest, I would think it'd be great to see a homebrew with a third pillar in terms of sound style. I played Atlantian last night and that squirrel sound is so distinct to me now, it reminds me of how unique the various studio's games sounded, and made me hopeful that in a world with Squirrel Aetherbyte, and CD Henshin, it would be rad to have a Deflemaskedasstrophy :P


If Arkhan doesn't have the time/interest, and you can wait a few months for sound, then this *will* get done to at-least a usable-if-not-perfect level. It isn't rocket-science, just finicky.

Thanks dude, any deflemask HuC support will be better than none, juding by the community support of deflemask it should open the door to a lot of projects having musicians rather than fumbly passionate non-musicians trying to pack some sound into their projects (see: me :P )

Michirin9801

  • Hero Member
  • *****
  • Posts: 589
Re: Huzak - Yet another music driver
« Reply #63 on: January 11, 2017, 07:08:51 AM »
OK, thanks guys, those are useful answers, and I'll ask more questions later on, but first, perhaps I should go back and explain what my problem is ...

It's all a case of exactly *when* you change the row timing, and the interaction of that new timing with some of the effects commands, and especially, how to process things efficiently so that we're not paying an undue cost for something that rarely (if ever) happens.

The issue that I have, is that you can change the row speed, and that it effects the length of the exact row that you issue the new speed on.

So if you're on the 1st row in a pattern, and you change Speed1 (with effect 09xx), then that speed is used (or it appears to be used, to me) as the duration of that row.

You can set that effect *anywhere* in the row, which means that the driver will process some, or all, of the other channel's notes/effects before the row speed is changed.

The problem is that some effects commands (particularly Note Delay and Note Cut) need to know what the exact row speed *will* be, and they need to know it as soon as they're encountered during the notes/effects for that row.

Deflemask can get around this chicken-and-egg problem just by scanning the row first and setting the new row speed (if there is one) before processing any of the other notes/effects on the row.

We can't do that (practically) in a sound driver.

I need to decide how to work around that problem.

BTW ... the issue here is really with the "Note Delay" effect.

Is that effect even useful anymore, now that you can achieve so much with the Envelope/Arpeggio/Wave Macros? (Which AFAIK eliminate the need for the weird 1:7 timings that I've seen used).

FYI ... just ignoring that *one* effect would make all of my problems go away (the Note Cut *can* be processed a little-less efficiently, but still work).



One solution is to automatically create a separate invisible "timing" channel, and move all of the changes in row speed into that channel while converting the .dmf file.

It's a bit of a PITA, and will waste some memory for songs that don't change their timings, and cost a *little* bit of extra processing time ... but it has the advantage that it will work reliably, and keep the what-you-see-is-what-you-hear advantage that Deflemask offers.



The alternate solution, is to strip out the timing info, and have the driver use its own timing, for example, the 8 different row speeds that I suggested earlier.

The advantage here is that it is practically free to process, takes almost no extra memory, it gives you very fine-grained control over the tempo for a song, and that it makes changing the tempo *inside-the-game* very, very easy (for boss-rush tracks when the tune gets faster and faster).

But ... even though those 8 speed-settings could be initialized from the settings in the .dmf file when it is converted, you would lose the flexibility to change the row-speed at *any* time within the song data itself, and so you'd lose a bit of the what-you-see-is-what-you-hear advantage.



Now, as a programmer, I find the 2nd solution to be the most-elegant and efficient ... but I'm not the guy that makes the music.

What do you guys feel? Which alternative sounds better to you, and/or can you just live without "Note Delay"?  :-k

Or ... perhaps I'll just take a very long walk and *possibly* figure out a way to work around the problem.  ](*,)
The Note Delay effect (EDxx) works by, well, delaying the note by the number of ticks you set it to, say if your song plays at 3 ticks per row in both the even and odd rows, but you want a note in one row to play 2 ticks afterwards than it should, so that note would play in between the two rows, then you can set the effect to ED02 and voila! The note will play in between the two rows!
Its 'usefulness' is debatable as a work-around can be reached by using the 09xx and 0Fxx effects for the pattern that uses it, however I have used it in a couple of my songs and it does its job pretty well!
But its job is to give you more freedom of where to put your notes in the slower songs, and in order to work around that you'd have to do some pretty complicated tempo-changing and pattern breaking which is only gonna further clutter the patterns... That said though, its use is relatively rare...

Personally I feel that the "Invisible Timing Channel" alternative would be much easier to deal with on my end, but I could live with the 8 different row speeds alternative, as for the 09xx/0Fxx and the Note Delay effects, you're gonna have to pick one of the two to support, because dropping both would really limit what we can do...
Oh and, the Note Cut effect is a must-have, I use it constantly!

My suggestion is to look for these specific effects and give them priority in this order:
09xx > 0Fxx > EDxx > ECxx
And after checking if any one or more of these effects is in the row, you then check the notes and the other effects, because that way the driver would be sure to know how many ticks that particular row will last for, then would know to delay a note by a set amount of ticks, and then would know to cut that note that set amount of ticks later, and after it knew all of that it would actually go and play the notes!

But in the case you use the 8 different row speeds solution, maybe you could check the clock speed value in Deflemask to make an approximation of the speed you should use depending on what clock speed is used instead of actually changing the clock speed, that way the users would be able to use that to know what tempo their song would use and have more of an idea of what the song would sound like in your driver!

elmer

  • Hero Member
  • *****
  • Posts: 2154
Re: Huzak - Yet another music driver
« Reply #64 on: January 11, 2017, 09:02:19 AM »
Personally I feel that the "Invisible Timing Channel" alternative would be much easier to deal with on my end, but I could live with the 8 different row speeds alternative, as for the 09xx/0Fxx and the Note Delay effects, you're gonna have to pick one of the two to support, because dropping both would really limit what we can do...
Oh and, the Note Cut effect is a must-have, I use it constantly!

I don't want to remove any of the capabilities, unless I absolutely *have* to ... it would be both ugly, and rather spoil the point of using a pre-exisiting GUI tool like Deflemask in the first place.

Having said which ... there's definitely an "order" in which individual effects will be implemented, and some, like Global Fine Tune, Arpeggio (the effect, not the macro), and the LFO effects, all very low on my priority list.

Now, since you mentioned "Note Cut" ... can you tell me if it acts as a non-row-aligned Note OFF, or if it actually fades out the note over the time of the "Note Cut" length parameter?  :-k


My suggestion is to look for these specific effects and give them priority in this order:
09xx > 0Fxx > EDxx > ECxx
And after checking if any one or more of these effects is in the row, you then check the notes and the other effects, because that way the driver would be sure to know how many ticks that particular row will last for, then would know to delay a note by a set amount of ticks, and then would know to cut that note that set amount of ticks later, and after it knew all of that it would actually go and play the notes!

Hahaha ... yah ... well sure, I understand that that is the *behavior* that needs to be implemented, but it's rather more complicated than that in terms of converting the deflemask data efficiently, and making the driver actually run fast.  :wink:

I took that long walk, and have come up with a decent solution to the problem, but it still uses up a few more cycles of CPU time than I really like ... and that irks me.  :(


The root-cause of the problem is really one of whether you decide on exactly how many 1/60s increments every row & note takes when you actually convert the .dmf file on your PC, or whether you leave that until you are actually running on the PCE.

You've arrived here in the middle of a longer-running argument/debate ... and that's the question of how to practically achieve both different, and differing tempos in songs.

I think that we pretty much all agree (now) that songs can have different tempos from each other, or within a tune, just by changing how many 1/60s increments a 1/4 note lasts ... basically, in the case of Deflemask, by setting those row speed values when you create your tune.

The question then becomes ... how do you achieve differing tempos, i.e. a tempo that keeps on speeding up as the tune keeps on playing?

There are 2 ways to make that happen ...


One way is to actually make your tune speed up in Deflemask, just by copying patterns and changing the row speeds.

You end up with a longer tune in Deflemask that way, potentially *much* longer, but at least it is the musician that has complete control of when/how the tune speeds up.


The other way is to avoid using row-speed-effects in the tune at all, and give the game programmer some way to change those row-speed values inside the game, especially when the player does something ... like actually land a blow on the boss monster.

That's probably going to both sound and feel the best for the player ... but it's a bit of a PITA for the driver guy, because the exact timings of things like your Note Delay and Note Cut cannot be determined when the .dmf file is converted on the PC, so the driver itself has to know how to handle them at runtime ... and everything that the driver has to keep track of and decide at runtime adds extra processing cycles and memory usage for code.  ](*,)


The question is ... what do both musicians and developers really want (and everything is NOT an acceptible answer)?

It is *much* easier (for me) to make all of these timing decisions on the PC, when the tune is converted.

Michirin9801

  • Hero Member
  • *****
  • Posts: 589
Re: Huzak - Yet another music driver
« Reply #65 on: January 11, 2017, 09:42:33 AM »
Now, since you mentioned "Note Cut" ... can you tell me if it acts as a non-row-aligned Note OFF, or if it actually fades out the note over the time of the "Note Cut" length parameter?  :-k
It's a non-row-aligned Note OFF trigger, nothing more, but there is a fade out effect which is the 0Axx effect, but it's rubbish and I never use it, if I want to fade out a note I manually lower the volume of the channel in the volume column...
Using the Note Cut effect I can give the bass a little more punch by cutting it off on the very tick right before the next note on every note, it makes baselines on the PCE sound noticeably better ;3
I also use the Note Cut effect on various other instances like when I want to play the same note again in the lead or the harmonic support and make it more noticeable or more punch-y depending on what I want to do... It's a VERY useful effect ^^

I took that long walk, and have come up with a decent solution to the problem, but it still uses up a few more cycles of CPU time than I really like ... and that irks me.  :(


The root-cause of the problem is really one of whether you decide on exactly how many 1/60s increments every row & note takes when you actually convert the .dmf file on your PC, or whether you leave that until you are actually running on the PCE.

You've arrived here in the middle of a longer-running argument/debate ... and that's the question of how to practically achieve both different, and differing tempos in songs.

I think that we pretty much all agree (now) that songs can have different tempos from each other, or within a tune, just by changing how many 1/60s increments a 1/4 note lasts ... basically, in the case of Deflemask, by setting those row speed values when you create your tune.

The question then becomes ... how do you achieve differing tempos, i.e. a tempo that keeps on speeding up as the tune keeps on playing?

There are 2 ways to make that happen ...


One way is to actually make your tune speed up in Deflemask, just by copying patterns and changing the row speeds.

You end up with a longer tune in Deflemask that way, potentially *much* longer, but at least it is the musician that has complete control of when/how the tune speeds up.


The other way is to avoid using row-speed-effects in the tune at all, and give the game programmer some way to change those row-speed values inside the game, especially when the player does something ... like actually land a blow on the boss monster.

That's probably going to both sound and feel the best for the player ... but it's a bit of a PITA for the driver guy, because the exact timings of things like your Note Delay and Note Cut cannot be determined when the .dmf file is converted on the PC, so the driver itself has to know how to handle them at runtime ... and everything that the driver has to keep track of and decide at runtime adds extra processing cycles and memory usage for code.  ](*,)


The question is ... what do both musicians and developers really want (and everything is NOT an acceptible answer)?

It is *much* easier (for me) to make all of these timing decisions on the PC, when the tune is converted.

Umm... Now that you put it like that...
You know, I've only once needed to make a song that goes faster after a while, but it only increased its tempo once so just one extra pattern was enough to carry the effect over to the whole rest of the song, so I personally think that having the different tempos is what really is more important, but in the cases where the composer/programmer/team wants to have a song that has differing tempos, which I believe to be very specific, then maybe give them the option to ignore the row speed effects and let the programmer handle the song's tempo (I mean, if they really want the song to get faster or slower dynamically they might as well)

Of course this is just my own narrow perspective, maybe a ton of people do want differing tempos and I just don't see that? Well I know I pretty much don't need them, but I do need the different tempos...
« Last Edit: January 11, 2017, 09:47:07 AM by Michirin9801 »

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: Huzak - Yet another music driver
« Reply #66 on: January 11, 2017, 10:27:29 AM »
So, where is this at?

DK I gotta request you to improve your bedside manner :P


Hah, I was trying to get things back on topic, rather than the endless MML debate that seemed to flood this thread. And yeah, I'm a bit rough around the edges.
Hey, you.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: Huzak - Yet another music driver
« Reply #67 on: January 11, 2017, 11:20:15 AM »
To be honest, I would think it'd be great to see a homebrew with a third pillar in terms of sound style. I played Atlantian last night and that squirrel sound is so distinct to me now, it reminds me of how unique the various studio's games sounded, and made me hopeful that in a world with Squirrel Aetherbyte, and CD Henshin, it would be rad to have a Deflemaskedasstrophy :P


Well, Squirrel only sounds like that because I'm basically the only one using it.  That's not Squirrel sound, that's just how stuff I write tends to sound, lol.

Other musicians will get different results.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

Gredler

  • Guest
Re: Huzak - Yet another music driver
« Reply #68 on: January 11, 2017, 11:37:57 AM »
Well, Squirrel only sounds like that because I'm basically the only one using it.  That's not Squirrel sound, that's just how stuff I write tends to sound, lol.

Other musicians will get different results.

Oh I don't doubt it. Cabbage has made some stuff for us that sound different than what you make, I was more referring that if we had to beg you to do music for us then it would sound similar to Atlantean

Michirin9801

  • Hero Member
  • *****
  • Posts: 589
Re: Huzak - Yet another music driver
« Reply #69 on: January 11, 2017, 02:40:42 PM »
To be honest, I would think it'd be great to see a homebrew with a third pillar in terms of sound style. I played Atlantian last night and that squirrel sound is so distinct to me now, it reminds me of how unique the various studio's games sounded, and made me hopeful that in a world with Squirrel Aetherbyte, and CD Henshin, it would be rad to have a Deflemaskedasstrophy :P


Well, Squirrel only sounds like that because I'm basically the only one using it.  That's not Squirrel sound, that's just how stuff I write tends to sound, lol.

Other musicians will get different results.
I'd also say that about Deflemask's PCE users, each one has pretty much their own style, some people make PCE music that just uses the system as an "NES on-steroids" (Which honestly, I disapprove) Others have a style closer to early Hudson but with samples, others can really take advantage of what the system can sound like, but with no regard for sound effects so a noticeable chunk of the song would have to be cut off to play SFX if used in a real game, as for me, I tend to cover a lot of Japanese Computer FM songs so I borrow my style a lot from them with my instruments, but I'm also always trying to get all the reverb that I can out of the system because SNES fan...
One thing that I really like to do, is whenever there's a repeating note progression (which happens a lot in the songs I like) or just one channel playing a new note on every other row, I can manage some single-channel delay/reverb by filling in the empty rows with whichever note came 3 rows before, but at a lower volume and panned slightly... To do that of course I have to constantly adjust the panning and the volume of the channel being used for that, but it works wonders and I free up a channel to do reverb on another instrument ;3
Do any other Deflemask users do that? I haven't seen a single one, the same way that there are things that they do that I don't... (Like use triangles, Half Pulses and Quarter Pulses, I only use those waveforms when absolutely needed)

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: Huzak - Yet another music driver
« Reply #70 on: January 12, 2017, 01:28:51 AM »
Well, Squirrel only sounds like that because I'm basically the only one using it.  That's not Squirrel sound, that's just how stuff I write tends to sound, lol.

Other musicians will get different results.

Oh I don't doubt it. Cabbage has made some stuff for us that sound different than what you make, I was more referring that if we had to beg you to do music for us then it would sound similar to Atlantean

Nah, I could switch it up and make it sound retarded to fit your game.

I mean this in a good way, lol.

Your game has like, a cat vacuum.    PCE chiptune thrash metalesque stuff doesn't really go well.

It needs something more dorky.   If you do need music, let me know.   I have to do Barbarian for Duderdudes, too.   I might get to the title of that tonight for them.

[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

Gredler

  • Guest
Re: Huzak - Yet another music driver
« Reply #71 on: January 12, 2017, 06:38:06 AM »
Nah, I could switch it up and make it sound retarded to fit your game.

I mean this in a good way, lol.

My brother and I used to volunteer coach floor hockey at the Special Olympics, and the hockey helmets back then from the 90's looked like megaman's catastrophy's helmet, so maybe there is a subconscious homage to those days - but retarded is kinda a harsh word I would say lol. It was a lot of fun and very rewarding; we would play in a mini tournament where the coaching staff of each team from around the country would play against each other - and it was fun and fast paced. After the tournaments the kids would ask for autographs and assumed we were professionals, it was very cute and heartwarming. Maybe we can do a Special Olympics fundraiser using catastrophy somehow some day :)

Your game has like, a cat vacuum.    PCE chiptune thrash metalesque stuff doesn't really go well.

It needs something more dorky.

If you think jazz is dorky then you're right :) Something more jazzy than metal

As much as I enjoy thrash metal, and if I were to ever make a game design myself it would either be hip-hop or metal themed / scored.

 I agree that it's not the fit for catastrophy and DK's already put the kibosh on that idea, as my first squirrel attempts were metal bass and drum lines, and the only song we have now is the one I made which is a very basic hip hop drum line my ignorant ass thinks :P

We will want to try to do Jazz standard songs if we don't have someone who wants to compose for the game; to give you an idea of what we had in mind would be something like SingSing:
("8 bit" vesion came up in earch,
).

I tried to do Sweet Georgia Brown in squirrel using royalty free midis, and it was turning out like hot garbage before I gave up :P
« Last Edit: January 12, 2017, 06:54:06 AM by Gredler »

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: Huzak - Yet another music driver
« Reply #72 on: January 12, 2017, 06:50:04 AM »
I can try to do something for you.   lol.

Jazz isn't my thing though really. 
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

elmer

  • Hero Member
  • *****
  • Posts: 2154
Re: Huzak - Yet another music driver
« Reply #73 on: January 13, 2017, 04:25:47 PM »
Now, since you mentioned "Note Cut" ... can you tell me if it acts as a non-row-aligned Note OFF, or if it actually fades out the note over the time of the "Note Cut" length parameter?  :-k
It's a non-row-aligned Note OFF trigger, nothing more, but there is a fade out effect which is the 0Axx effect, but it's rubbish and I never use it, if I want to fade out a note I manually lower the volume of the channel in the volume column...

Thanks!  :)

Yep, that's easy-enough to implement.

BTW ... the "issue", such-as-it-is (*was*, actually, since I figured-out how to do it semi-efficiently), is what to do if the Note Delay or Note Cut time is longer than the row speed.  :-k

Sure ... that *shouldn't* ever happen, but it *could*, especially if the game is speeding-up the tempo ... and so the driver needs to have code written to handle the possibility.

The deflemask manual states that both effects will be "ignored" if that happens ... but then doesn't state what "ignored" will actually sound like.  #-o

I've chosen to implement "Note Delay" so that if the delay is longer than the row speed, then the note will get triggered at the end of the row (and possibly be *immediately* overwritten, in the same update, by a note on the next row).

For the "Note Cut", I have the option of either triggering the "OFF" at the end of the row, or just leaving it to continue counting-down, or even just "ignoring" the Note Cut and throwing it away.

I don't know which choice would sound "best" to a musician.


**********************

The next question that I have is about those "Fixed Arpeggio" macros, that allow you to enter a note value of 0..99.

What is a "0" note in that macro? Is it deflemask's C#0?

What note value is 440Hz A (A3 in deflemask)?

BTW ... it's a bit annoying that Deflemask says that the PCE is limited to C#0..B6 and then allows you to enter higher octave values than that.  ](*,)

The PCE allows 4 notes lower than that, and a whole octave higher, too, but with a probably-unacceptable error drift on a couple of the note frequencies at the high end (i.e. the higher octave isn't worth it).


**********************

Quick update ... the converted .dmf data (including waveforms and instruments, but NOT samples) is now being spit out as a source file for the PCEAS assembler, and I'm working on rewriting bits of the huzak driver itself to handle the new data.  :D

Michirin9801

  • Hero Member
  • *****
  • Posts: 589
Re: Huzak - Yet another music driver
« Reply #74 on: January 13, 2017, 04:50:36 PM »
For the "Note Cut", I have the option of either triggering the "OFF" at the end of the row, or just leaving it to continue counting-down, or even just "ignoring" the Note Cut and throwing it away.

I don't know which choice would sound "best" to a musician.
I'd say do the former, if the musician put the note off effect in there, it's because they want that note to be cut, and would probably miss the note cut if it wasn't there...

The next question that I have is about those "Fixed Arpeggio" macros, that allow you to enter a note value of 0..99.

What is a "0" note in that macro? Is it deflemask's C#0?

What note value is 440Hz A (A3 in deflemask)?
I just went and checked, both the "0" and "1" notes in the fixed arpeggio are the same note: C#0.
A-3 is note 45.

BTW ... it's a bit annoying that Deflemask says that the PCE is limited to C#0..B6 and then allows you to enter higher octave values than that.  ](*,)

The PCE allows 4 notes lower than that, and a whole octave higher, too, but with a probably-unacceptable error drift on a couple of the note frequencies at the high end (i.e. the higher octave isn't worth it).
Considering how dead the Deflemask forum is at the moment, I doubt asking about it will do anything... He's yet to even answer to the suggestions I've made aeons ago...

Quick update ... the converted .dmf data (including waveforms and instruments, but NOT samples) is now being spit out as a source file for the PCEAS assembler, and I'm working on rewriting bits of the huzak driver itself to handle the new data.  :D

Hooray~!!
Oh, don't worry about samples right now, first get the thing up and running! I can't wait to hear the results ^^