Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v5.6.0 Win x64 : cannot select MIDI-Ports #152

Open
Possemo opened this issue Feb 5, 2021 · 10 comments
Open

v5.6.0 Win x64 : cannot select MIDI-Ports #152

Possemo opened this issue Feb 5, 2021 · 10 comments

Comments

@Possemo
Copy link

Possemo commented Feb 5, 2021

image

Only device I can select is the standard "Microsoft GS Wavetable Synth". This one seems to work, other ones throw the above error.
I tested Standalone and VST3, it's the same on both.

Btw. on the VST3 "input from pluginhost" does not seem to work, "output to pluginhost" does not pass sysex. Output does work for notes and program changes tough. But this is another issue I'd say is on much lower priority than the non-working MIDI-ports

@ConditionalInstability
Copy link

I see the same problem (Windows 10). All my devices appear in the menu list, but any attempt to connect produces the error shown by @Possemo
This applies to hardware connected using the built-in windows driver, the Roland proprietary midi driver and virtual midi cables from loopMidi. The usual red or green status messages at the bottom of the ctrlr window do not appear, nor do the happy/sad faces in the midi menu.

Otherwise, JUCE 6 looks very nice, and I'm looking forward to testing more!

@Possemo
Copy link
Author

Possemo commented Feb 6, 2021

I too think that it is the right way to progress and use the newest JUCE libs. This bug seems to come form the upgrade to JUCE 6, there are probably some changes needed in order to get it working again. Interestingly the "Microsoft GS Wavetable Synth" does work so it shouldn't be too hard to fix. I looked into it but my knowledge about C++ is too little. I saw that the demo from JUCE about MIDI-ports does it quite differently:
MidiDemo.h
The demo is impressive as you can select more than one MIDI input / MIDI output. It will mix and replicate data automatically. Well, this isn't needed for Ctrlr.

@Possemo
Copy link
Author

Possemo commented Feb 7, 2021

The pull request from dehnhardt "make it compile and work under Linux #151" fixes it! Great, thanks dehnhardt

@ConditionalInstability
Copy link

Is it really fixed @Possemo? I built ctrlr standalone with #151 and tested with the Reface CS panel. I could send data to my Reface, but I didn't get anything back. There was no error opening the input device, but nothing showed on the midi monitor when I moved a slider on the hardware instrument.
I should say that this is the first time I've built ctrlr (or anything else on Windows), so I may have made a dumb mistake somewhere.

@Possemo
Copy link
Author

Possemo commented Feb 8, 2021

I used vs2019 on Windows. My build seems to work ok. I have to say that I took the newest master branch and I added the changes from dehnhardt related to mididevices myself. This way I hoped to learn something... oh well. I tested it with my Matrix-1000 panel and it looks all ok - bidirectional MIDI communication, Lua scripts etc. Tested with the Matrix-1000 hardware synth. Also the vst plugins seem to work. There are some small bugs on vst3 but it's basically working ok as well.

@ConditionalInstability
Copy link

Thanks! I also used VS2019 on Windows, so it should work for me. I'll keep trying.

@keinstein
Copy link

I separated the patch for upgrading MIDI to the current JUCE implementation. See: dehnhardt#1

@ConditionalInstability
Copy link

After some testing, I see that midi is received, and I can fetch the value in lua and update the modulatorValue myself and see it reflected on the panel. The problem seems to be that ctrlr does not do it by itself. Has anyone else seen the same thing for modulators not using lua?

@Possemo
Copy link
Author

Possemo commented Feb 15, 2021

You mean that the sliders do not react to incoming midi? This has nothing to do with Lua (afaik). That never really worked for me, even with v5.3.201. My conclusion: you have to do that yourself with Lua scripts.
Look here: #131 Roman is aware of this issue.

@ConditionalInstability
Copy link

Thanks again @Possemo ! For me with v5.3.201, the sliders usually do react to incoming midi, both for CC and SysEx. The exception is a certain kind of Roland SysEx (#140), where the only solution was to write a lua script. Actually, the reason I started building ctrlr from source was so that I could fix that issue, but now there seems to be a deeper problem. It may not be worth trying to track it down if Roman is planning to redo that part of the code anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants