My plug-in works before saving the *.izz file but not after

Michel

mark

Dear JolkaP,

Please send me the user actor at mark [atta] troikatronix [dotta] com -- I'll have a look. Please let me know the version of Isadora you are using, and your operating system and operating system version as well.

Best Wishes,

Mark

JolkaP

Dear Mark,

I am sending it right now, thanks for your interest.

My operating system is Windows 7.
My version of Isadora is 1.3.0f24

Bye

JolkaP

Hello everybody,

Trying to figure out where the problem appears, I started again the construction of the actor by "step by step" modifications starting from the Sample Plugin delivered with Isadora SDK and verifying each time if I have problems after saving the file.

I think I found the moment where the message about inconsistent links appears. As I explained before, I was working on two kinds of actors, one that takes three entries: sound index, and two channel numbers, and plays the given sound two given channels; and another actor that does the same thing four times (see joint images). Now that I was adding modifications "step by step", I have this strange situation with two actors that do essentially nothing yet, one of them have three entries, the other twelve, and only the second one have the message I talked about when saved and recovered "This document contains inconsistent links beetween actors[...]"

@Mark: This means that there is a maximal numbers of entries? How much is the maximum? I send you more code by mail because the forum does not allow upload of *.cpp files

Goodbye

JolkaP

Oh,
I figured out why the message about "inconsistent links" appeared with the version of the actor with 12 entries. I made a mistake when defining the new property definition string on the larger actor, and there where repeated IDs in the property definition string.

Correcting this error makes that the message about "inconsistent links" does not appear anymore. But still I have a plug-in that works before saving but not after.

JolkaP

Hello everybody,

I found what is that makes the actor different before and after saving the file. In order to find the path to the file I will play to different channels, I use the following macro from the Isadora SDK
GetUTF8PathToCurrentDocument_()
(I think it is declared in the IsadoraCallbacks header)
Well, it is supposed to work differently if the file is saved or not, because in the first case it gives empty path, and in the second case it gives the path where the document was saved. So, the file I want to play has to be saved at the same folder as the Isadora document that will use it.
But even if both files are in the same folder, my actor doesn't work. I found that when I try to play a sound file from an already saved file with my actor inside, a control variable called isDeviceRecognized (that is inside my PluginInfo structure) changes to false just after using this macro. IMHO this is an unexpected behaviour, so I will send a bug report tomorrow (not now because I do not have all the code right now with me).
Bye,

JolkaP

As I explained yesterday, I found an unexpected behaviour little time after calling
GetUTF8PathToCurrentDocument_(izzyParamsPtr, inThingPtr, inMaxLen, outString)
from my actor. I thought it was because of this function, but in fact I am quite sure now it is not.

I call the function GetUTF8PathToCurrentDocument_ only from the HAndlePropertyChangeValue, when
the number of the audio file to be played change.
switch (inPropertyIndex1) {
case kInputSoundNum1:{
info->mSoundIndex[0] = (int)(inNewValue->u.ivalue);
if(info->mSoundIndex[0]>0){[...]
   info->fileName[0][255]='\0';
   ExecuteMediaCommand_(ip, inActorInfo, 0, kMediaGetName, kMediaTypeAudio, info->mSoundIndex[0], (long) info->fileName[0],sizeof(info->fileName[0]));
   char fpBuf[1024];
   Boolean success = GetUTF8PathToCurrentDocument_(ip, inActorInfo->mThing, sizeof(fpBuf), fpBuf);
   if (success==TRUE && IsRelativePathName(info->fileName[1])) {
       strncat(fpBuf, info->fileName[1], sizeof(fpBuf));
       strncpy(info->fileName[1],fpBuf, sizeof(fpBuf));
   }
   [...]
}[...]
}
break; [...]}

I am using Visual Studio 2008 on Windows 7, latest IsadoraSDK available on the troikatronix.com site and Isadora 1.3.0f24. In the code above, when I debug it with a VisualStudio debugger, I have three cases

when I put some file to play in a non saved Isadora document, the path I get from GetUTF8PathToCurrentDocument_ is some string that looks like an empty string and I can play the file.
when I save the file, the path I get is the absolute path to the place where I saved the Isadora file. So the file is correcly recognized, but strangely just after the code I copy-pasted above, I see that a private member of my actor called "isDeviceRecognized" and of type bool change from true value to false value. I don't know if this is the only variable that changes, neither I know why it changes. I use it as a condition to play sound inside my ReceiveMessage function, so in this case this unexpected change explains why no sound is played when calling my actor from a saved file.
when I open an already saved file from the instance of ISadora opened by the debugger, I have the same behaviour as in the case above (the case where I save the file from the instance of Isadora opened by the debugger)

If I debug with the five last lines of the code above commented, the unexpected change of the isDeviceRecognized does not happen. If I debug commenting only the isRelativePathName condition, the unexpected change of isDeviceRecognized still happen.

I tried also to manually reassign the true value to isDeviceRecognized, and if I do so, I can play up to one file at once from the debugger, but from the second file on it does not work anymore. I guess this is because isDeviceRecognized is not the only private variable that has unexpected changes.

Please, somebody can help me understand why after a call inside the "if instruction" to strncat and strncopy as in the code above, private members of my actor changes? And why this happens only inside already saved files?

JolkaP

Hello everybody,
My problem is solved,
We just found the origin of the error: it is something in strncat or strncopy function that was changing private members of the variable, maybe because the size passed to this functions was not right or maybe just because they are not sure functions. We changed to an sprintf function for whom it is not necessary to specify the length of the strings. Maybe because the size of fpBuf where I was keeping the path was small when the Isadora file was not saved yet, we did not see the problem until the *.izz file was saved.
Goodbye

DusX

Will something about this problem be noted in the SDK?

mark

Noted about ??? From what he said, I think it was a bug in their code, no?

-- M