#6 load_map: missing path initialization

[Albert Graef]

At the beginning of load_map in main.c there is a missing initialization of the path variable, which is later used to print the resolved pathname in verbose mode (-v). Also, there's an extra printout of the pathname at the beginning of the routine which isn't necessary.

A minimal witness triggering these bugs is attached (cf. test.omm):

/1/fader1 f, val : controlchange( 0, 1, 127*val );

Running this with osc2midi gives:

$ osc2midi -v -m test.omm 
Using map file test.omm
Using map file P}X��

The attached patch (load_map-path.diff) simplifies the code and fixes both bugs.

[Albert Graef]

Suggested patch.

[Albert Graef]

Spencer, I really tried hard to submit this as a pull request, as you recommended. I do know how to use those features on Github and Bitbucket, both as project maintainer and contributor. But sf.net's corresponding feature seems to be completely dysfunctional. My first fork of the osc2midi repo died with "missing metadata" as soon as I pushed my first commit to it and was unusable afterwards, and I can't even delete that fork anymore. My second attempt to fork your repo still hangs there "initializing" since an hour. And I wasn't able to find any useful documentation about that feature anywhere, so I've given up on it until sf.net bothers to fix their implementation.

So if you don't mind I'll just continue throwing patches at you. ;-)

[Albert Graef]

I've set up a clone of your repo on Bitbucket now, so that I can maintain my changes and bugfixes to your sources more easily. You can find that here: https://bitbucket.org/agraef/osc2midi

[ssj71]

that should work. I can merge from that repo manually without too much trouble. Thanks for trying with SF anyway. I have only just started using that feature here. Too bad it doesn't work.

[Albert Graef]

that should work. I can merge from that repo manually without too much trouble.

Thanks. I really prefer Bitbucket and Github for these kinds of things, as they're streamlined for DVCS and the corresponding workflows. And their web interfaces are much nicer and faster IMHO.

Thanks for trying with SF anyway. I have only just started using that feature here. Too bad it doesn't work.

Well, I guess they're still working on it. SF is great for what it is, in particular they have a decent file release system (neither Bitbucket nor Github provide much support there), I guess that's what they're mainly used for these days. But they're really late to the party when it comes to proper DVCS support. Let's hope that they get that into good shape eventually.

BTW, the second attempt at forking your repo on SF finally worked. :) But it took more than a day, so I think that an SF operator fixed that up manually. Anyway, if you don't mind then I'll just continue using my fork on Bitbucket. I'll pull your commits over after every round of changes so that the fork stays in sync.

[ssj71]

patch applied in master