Setting up a nomad debug environmment on windows (vista)

blue hell · Posted: Sat Apr 05, 2008 12:40 pm Post subject:

Added the latter as an external jar as well, and then I have one problem left :

Project nomad is missing required javea project "nmlibs", seems like a misconfiguration?

blue hell · Posted: Sat Apr 05, 2008 12:47 pm Post subject:

I just removed nmlibs from the projects tab in the java build path thingy .... andthen I get another error :

the project wa not built since its build path is incomplete. Cannot find the class file for java.lang.Object Shocked

that seems a fundamental thing wrong in my setup Laughing

chresan · Posted: Sat Apr 05, 2008 12:51 pm Post subject:

blue hell · Posted: Sat Apr 05, 2008 1:05 pm Post subject:

Told you it was a fundametal thingie Laughing

Ok, now I got 134 warnings ... that'better ... now when I try to run it's complaining about /nomad/nomad-source/net.sf.nmedit.nomad.boot.splash/dist/lib/nomad-splash.jar it is said to not exist ... but it is present and just sitting there smiling at me Rolling Eyes

chresan · Posted: Sat Apr 05, 2008 1:11 pm Post subject:

The warnings can be ignored - I have them too.

As for the nomad-splash.jar problem try Project->Clean and/or right click on Project-> Refresh and the run Nomad again. By the way, is the error in the console tab ? (Then show me the output)

blue hell · Posted: Sat Apr 05, 2008 1:14 pm Post subject:

It runs

blue hell · Posted: Sat Apr 05, 2008 1:23 pm Post subject:

And it debugs drunken

Right ... now I better start to understand what's going on, I looked at it a couple of years ago, it was pretty complicated and it looks like it still is ...

Thank you Christian, this would have takemn me a week without your help.

chresan · Posted: Sat Apr 05, 2008 1:27 pm Post subject:

blue hell · Posted: Sat Apr 05, 2008 1:34 pm Post subject:

chresan · Posted: Sat Apr 05, 2008 1:35 pm Post subject:

blue hell · Posted: Sat Apr 05, 2008 1:42 pm Post subject:

One more question for now .. how do I continue debugging after an exception stopped execution?

chresan · Posted: Sat Apr 05, 2008 1:43 pm Post subject:

chresan · Posted: Sat Apr 05, 2008 1:46 pm Post subject:

blue hell · Posted: Sat Apr 05, 2008 2:04 pm Post subject:

Yes I'm using the debug view, I looked in the wrong toolbar, I remember the icons now from a previous time I used Eclipse, for some reason I did not see them but I had been looking in the run menu and that one ha them as well now ... don't know what went wrong before then, I started the debug in a different way ...

are all timeout in ms?

I get a value of 120 742 860 496 when I break in SchedulingProtocol( ).heartbeatImpl() which seems a bit much ... like uninitialized (which should not be the case, the constructor sets it to zero) ...

chresan · Posted: Sat Apr 05, 2008 2:14 pm Post subject:

The timeout is thrown in the method heartbeatImpl() (in class net.sf.nmedit.jnmprotocol2.NmProtocol )

The timeout value in the exception in fact is the threshold when a timeout occurs. The value is in milliseconds and is initialised using System.currentTimeMillis() + TIMEOUT_INTERVAL.

I believe on windows the system.currentTimeMillis returns the time in milliseconds since the os was started.

blue hell · Posted: Sat Apr 05, 2008 3:08 pm Post subject:

A thing that seems note worthy is that while the program is waiting for a reply in the connect method only light messages are coming in from the synth and not the expected message type, so this may be an issue with a patch that is "too complicated"

chresan · Posted: Sat Apr 05, 2008 3:17 pm Post subject:

Which messages are sent to the synth before the exception occurs ?

Perhaps modify the method void send(MidiMessage midiMessage) throws MidiException in class AbstractNmProtocol:

chresan · Posted: Sat Apr 05, 2008 3:22 pm Post subject:

By the way, in class AbstractNmProtocol is a method
byte[] getNextReceivedSysexBytes() which tries to fix some sysex problems and might contain a bug.

Also the method MidiMessage.create() calls the method BitStream ensureIsValidSysex(BitStream stream) . Try to check if the method returns null at some point. Then the method is either buggy or the midi message is invalid.

blue hell · Posted: Sat Apr 05, 2008 3:28 pm Post subject:

Hmm, yes will do that, but meanwhile I made an empty patch to make things simpler, and the light message are gone and still things time out, so the lights are not the issue.

Is there a good point to set a similar log on reception? Preferrably beforethe bytes have been assembled into messages.

blue hell · Posted: Sat Apr 05, 2008 3:31 pm Post subject:

It sends one IAmMessage now and then it times out.

chresan · Posted: Sat Apr 05, 2008 3:38 pm Post subject:

The class AbstractNmProtocol contains the method

chresan · Posted: Sat Apr 05, 2008 3:49 pm Post subject:

Hm, interesting that the problem happens directly after the IAMmessage was sent.

The application flow is when Nordmodular.connect() is called it sends an IAMMessage (which identifies the editor) - then as reply the synth must send an IAMMessage to identifying itself.

This means that
- the IAM from the editor is sent but discarded somewhere between JDK->Vista (this is the most unlikely case in my opinion) since the synth does not receive the IAM message it does not send an reply
- the synth sends no IAM reply (also unlikely, otherwise the clavia editor would not work)
- the synth sends an IAM reply which is not supported by the protocol or is corrupted at some point

My tip is the last point, to debug this look especially in the MidiMessage.create method what happens. Does it throw an exception, is it even called ?

blue hell · Posted: Sat Apr 05, 2008 3:57 pm Post subject:

I must import something to be able to use PDLUtils I guess, but I used a simple "received: <something>" printout instead to see if I get any reception at all.

And indeed I do not receive anything at all.

I'm pretty sure though that I did have reception when I had the complicated patch loaded, so apparently the IAmMessage gets lost or something, or the reply on it of course .. but that seems less likely.

blue hell · Posted: Sat Apr 05, 2008 4:02 pm Post subject:

Ok, I can confirm that reception is possible, I loaded a complicated patch again and now I get the "recv : <something>" message printing and also the accept() method in NmMessageAcceptor.java (where I had a breakpoint) was hit.

Edit : in NmMessageAcceptor.accept() I mean.

Edit : fixed some typos

chresan · Posted: Sat Apr 05, 2008 4:11 pm Post subject: