Page 23 of 30

Re: Version 0.5 preview

Posted: Sun Dec 13, 2015 1:18 am
by HertzDevil
Since 0.4.6 (and most likely 0.4.5 as well), obtaining a non-existent instrument from the exporter interface causes FamiTracker to crash:

Code: Select all

CInstrument2A03Interface const *CFamiTrackerDocWrapper::Get2A03Instrument(int Instrument) const
{
   CInstrument *pInstrument = m_pDocument->GetInstrument(Instrument);
   pInstrument->Release(); // Prevent memory leak, no instrument will be removed during export
   return dynamic_cast<CInstrument2A03Interface const *>(pInstrument);
}
Undefined behaviour occurs if pInstrument points to nothing. Either it should be returned immediately, or CInstrumentContainer should be used if it is accessible from the wrapper component. All beta builds of 0.5.0 have this issue as well.

Re: Version 0.5 preview

Posted: Sun Dec 13, 2015 1:33 am
by iYamWhatIYam
Where would the non-existent instrument come from, I wonder? Is it, perhaps, a bug in the export? Or perhaps, was it created, deleted, but still remained in the text, even after the file was still created as text after a change? I find it rather strange. Hopefully this can be addressed in the official build.

Re: Version 0.5 preview

Posted: Sun Dec 13, 2015 1:51 am
by HertzDevil
The exporter interface has absolutely nothing to do with the text exporter as it is right now. When a DLL exporter in the /plugins/ directory retrieves an instrument from the current FTM, it must be able to do so for any instrument index, rather than use a separate method to determine whether the instrument of the given type actually exists. For instance, Gradualore's text exporter does this:

Code: Select all

DLL_EXPORT bool Export( FamitrackerDocInterface const* doc, const char* fileName)
{
   Instrument2A03Handle ins;
   // ...
   for(i=0;i<0x40;i++)
   {
      ins=doc->Get2A03Instrument(i);

      if(ins)
      {
         os<<"[Instrument"<<i<<"]"<<endl;
         // ...
If an instrument of the given index does not exist, the instrument is simply not in the current module per se.

(Gradualore's text exporter produced results similar to rainwarrior's, but it was available as an extra format item on the NSF export dialog, and therefore had no text import capabilities, although if jsr decides to maintain the current interfaces and wrappers, it might be possible to write importer plugins too without having to compile them within the tracker build.)

Re: Version 0.5 preview

Posted: Sun Dec 13, 2015 2:48 am
by iYamWhatIYam
Oh. Then how the hell does this happen? Surely there's a coding boo-boo somewhere.

Re: Version 0.5 preview

Posted: Sun Dec 13, 2015 9:54 pm
by TheMudkipMaster12
So I removed all of the unused instruments and I hit play and then FT crashed. I tried it again to see if I could replicate it, but it worked normally the 2nd time. Not much I can say :? , but it did create a .dmp file. Also, my module used a custom engine speed.

Re: Version 0.5 preview

Posted: Thu Dec 17, 2015 8:05 pm
by HertzDevil
Consider the following:

Code: Select all

     # : Pulse 1
ROW 00 : C-3 01 . F04
ROW 01 : ... 00 . ...
ROW 02 : D-3 .. . ...
Volume sequence 0 is { | 7 3 }. Instrument 00 is blank, and the volume sequence index is 0; instrument 01 uses volume sequence 0. There are different behaviours of loading blank instrument sequences, depending on the volume output of this pattern:
  1. 7 3 7 3 3 3 3 3 15 15 15 15; on row 01, the blank instrument with no note stops the instrument from setting new instrument volume values, and then on row 02 the instrument volume is reset to its default value. This is probably the correct behaviour.
  2. 7 3 7 3 7 3 7 3 15 15 15 15; the blank instrument on row 01 does not stop the volume sequence, but on row 02 the note does that.
  3. 7 3 7 3 7 3 7 3 3 3 3 3; the note on row 02 does not stop the volume sequence even though the instrument should be triggered. This is certainly an incorrect behaviour; see this FTM for an example.
All exported NSFs exhibit behaviour 1. FamiTracker 0.5.0 beta 2 or before exhibit behaviour 2, however if instrument 00's volume sequence index is not 0, even though it is disabled, then behaviour 1 is shown. Version 0.5.0 beta 3 and onward display behaviour 3; moreover if instrument 00 points to a different volume sequence without using it, the volume output will be 7 3 7 3 3 3 3 3 3 3 3 3.

All these suggest that, since 0.5.0 beta 3, if a blank sequence is loaded before a new note is triggered, the new note will not reset the instrument to some default value. For volume this is 0x0F (0x1F on FDS), and for duty cycle this is the Vxx value (except perhaps N163 under some circumstances). Arpeggio sequences and pitch sequences are unaffected since FamiTracker calls CChannelHandler::SetNote(int) and CChannelHandler::SetPeriod(int) on new notes even without instruments.

Behaviour 2 can be fixed by adding a simple check to ensure that disabled sequence types do not affect sequence loading:

Code: Select all

bool CChannelHandler2A03::HandleInstrument(int Instrument, bool Trigger, bool NewInstrument)
{
   // ...
   for (int i = 0; i < CInstrument2A03::SEQUENCE_COUNT; ++i) {
      const CSequence *pSequence = pDocument->GetSequence(SNDCHIP_NONE, pInstrument->GetSeqIndex(i), i);
      int Enable = pInstrument->GetSeqEnable(i);
      if (!Enable)             // put this before the other conditional clause
         ClearSequence(i);
      else if (Trigger || !IsSequenceEqual(i, pSequence) || Enable > GetSequenceState(i)) {
         SetupSequence(i, pSequence);
      }
   }
   // ...
   // the same applies for all channels using sequence instruments

Re: Version 0.5 preview

Posted: Fri Dec 25, 2015 1:12 pm
by ollaxe
The Qxx effect (and presumably the Rxx effect too) is (are) really glitchy. Listen to this a few times and you'll see that it's all over the place.

Edit: I forgot to mention, this only happens when using the sunsoft 5B chip. Sorry!

Re: Version 0.5 preview

Posted: Fri Dec 25, 2015 9:22 pm
by Shywolf
When using the 5B ENV at a slow setting on one channel, the .nsf export has the ENV be retriggered whenever notes are played on the other 5B channels. Works properly in-tracker, though.

Re: Version 0.5 preview

Posted: Wed Dec 30, 2015 2:41 am
by recme
i have some suggestions. can the insert button (ins) on famitracker be customized? pressing fn + prt sc can get oh so annoying at times.

also, can buffer length be a little more precise? it always has to be either on 52, 57, 62, etc.. is there any reason why its like this?

Re: Version 0.5 preview

Posted: Wed Dec 30, 2015 3:04 am
by Stratelier
recme wrote:i have some suggestions. can the insert button (ins) on famitracker be customized? pressing fn + prt sc can get oh so annoying at times.

You have one of those laptops too?