Re: [midishare-devel] Input from MIDI device

[Ashley W. <as...@dc...>]

I haven't previously installed MidiShare.  When I sent my earlier 
emails, I was using 1.90.  I still have no luck with this version.

However I've just tried the 1.88 version, and all seems fine -- the 
behaviour of msDrivers is as Jay describes: changes I make there are 
remembered between launches, and msDisplay shows data from the 
controller keyboard :)

I notice that 1.88 creates a 
~/Library/Preferences/MidiShare/msMidiDriver.ini file, which 1.90 did 
not.  (This answers my question about where msDriver changes are saved 
to.)

So there is a definite bug in 1.90 on my system.

Both versions of the installer have a bug.  Given that both versions 
have it, it isn't the cause of my issue, but it is a problem.  The 
installer changes the permissions on my Applications folder to "Owner: 
system", meaning I then have only read permissions there.  The 
MidiShare folder is also owned by system.  I can fix this with "sudo 
chown -R ashley:admin /Applications/MidiShare" but that doesn't have 
any affect on my original (can't read data from controller keyboard) 
problem.

Here are some answers to your questions, Jay... I'm talking about 1.90 
now:

On 10 Jun 2005, at 5:48 pm, Jay Vaughan wrote:
>> Unfortunately the above sequence doesn't work for me.  At step 1, I
>> don't see the EDIROL input or output slots.
>
> open 'audio/midi setup' and look for the driver there.  confirm that 
> it is there (okay, midi monitor saw it, fair enough).

Yup, the driver is there in Apple's Audio MIDI Setup application.

> then .. open msDrivers and wait.  watch Console.app.  check the 
> midishare.log file in ~/Library/Preferences/MidiShare/ .. notice all 
> alerts/msgs.
>
> copy/cut/paste to the list for dissection ..

No clues here, I'm afraid.

Every time I open msDrivers:

* ~/Library/Preferences/MidiShare has a line added like this:
[06/13/05 15:29:41]: MidiShare: open time interrupt using a timer - 
time resolution is 1

... there isn't anything else in that file.

* console.log (shown in Console.app) has a line added like this:
## Component Manager: attempting to find symbols in a component alias 
of type (regR/carP/x!bt)

* There is nothing added to system.log (shown in Console.app).

>> If msDisplay is running *before* I launch msDrivers, then I see the
>> EDIROL slots.
>
> close msDisplay, open msDrivers all by itself.  msDrivers -should- see 
> the EDIROL interface .. however, it can sometimes take a second for 
> the interface to refresh.

Unless msDisplay (or Apple's Audio MIDI Setup app) is running before I 
launch msDrivers, I don't see the EDIROL interface.  I've tried waited 
several minutes for the interface to refresh!

>> Also, if I have Apple's Audio MIDI Setup application
>> running before I launch msDrivers, I see the EDIROL slots.  If I
>> just launch msDrivers on its own, I don't get the EDIROL information
>> and so can't make the connection to port 0.
>
>> Also the changes I make in msDrivers don't seem to be saved when I
>> quit and restart it.  Should this be happening?
>
> yes, this is a clue.  check the permissions on your midishare.ini 
> file.  delete it, or move it out the way (mv) and try to start up 
> msDrivers again ..

~/Library/Preferences/MidiShare/midishare.ini seems to be created if it 
doesn't already exist whenever msDrivers or msDisplay are launched.  
However the state of the file never changes from the default.

(Note from above that in 1.90, the msMidiDriver.ini file is not 
created, which appears to be the cause of my problem.)

>> (I think you imply
>> that it should, since you say that "the new connections state is
>> saved".)  Where should the changes be saved to?  Perhaps there is a
>> permissions problem?
>
> have you had earlier versions of MidiShare onboard, or is this your 
> first install?

This is my first install.

>> I've created a new test user to check for conflicts with my setup,
>> and the results are the same.  I've also tried rebooting the machine.
>
> check all logs, lets see if they provide a clue..

Logs provided above -- no clues, I'm afraid.

... so now I have a working 1.88 installation.  I guess this is OK to 
use for experimental development.  I'm willing to try other experiments 
to try and diagnose the problem in 1.90 -- let me know what to try.

Ashley.