make it compile and work under Linux by dehnhardt · Pull Request #151 · RomanKubiak/ctrlr

dehnhardt · 2021-02-05T14:53:13Z

I had a hard time getting ctrlr to work - at least partly - under Ubuntu 20.04.
With this changes

compilation is successfull
I can run ctrl - but only when compiled in debug mode. In release mode I get an exception somewhere in the early startup phase.
MIDI ports can be opened
Receiving of MIDI is successfull
Sending does not work
I don't think this PR can be applied at all, but it might give you some hints where changes are required for Linux.

dehnhardt · 2021-02-05T14:54:00Z

.gitignore

+Packaging/**
+.vscode/**
+Source/Core/stdafx_luabind.h.gch
+Source/Core/stdafx.h.gch


Might be ok to ignore generated files

This is only Windows related and should be removed from the patch

dehnhardt · 2021-02-05T14:54:28Z

Builds/LinuxMakefile/Makefile

  JUCE_CFLAGS += $(JUCE_CPPFLAGS) $(TARGET_ARCH) -fPIC -g -ggdb -O0 -w $(CFLAGS)
  JUCE_CXXFLAGS += $(JUCE_CFLAGS) -std=gnu++14 $(CXXFLAGS)
-  JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell pkg-config --libs alsa freetype2 libcurl) -fvisibility=hidden -lrt -ldl -lpthread -lz -ludev -lbfd $(LDFLAGS)
+  JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell pkg-config --libs alsa x11 freetype2 libcurl) -fvisibility=hidden -lrt -ldl -lpthread -lz -ludev -lbfd $(LDFLAGS)


x11 is still needed

dehnhardt · 2021-02-05T14:55:38Z

Builds/LinuxMakefile/Makefile

 	-$(V_AT)mkdir -p $(JUCE_VSTDESTDIR)
 	-$(V_AT)cp -R $(JUCE_COPYCMD_VST)

-$(JUCE_OUTDIR)/$(JUCE_TARGET_VST3) : $(OBJECTS_VST3) $(RESOURCES) $(JUCE_OUTDIR)/$(JUCE_TARGET_SHARED_CODE)


these parts in the Makefile gives errors, Is VST3 Relevant for Linux at all?

yes

But I'd think this is a bug in Projucer

these parts in the Makefile gives errors, Is VST3 Relevant for Linux at all?

Why would VST3 not be "relevant" for Linux?

dehnhardt · 2021-02-05T14:56:15Z

Builds/LinuxMakefile/build.sh

 	echo "stadfx.h"
-	g++  -w -std=c++14 -D "LINUX=1" -D "NDEBUG=1" \
-		-D "JUCE_FORCE_DEBUG=0" -D "CTRLR_NIGHTLY=1" \
+	g++  -w -std=c++14 -D "LINUX=1" -D "NDEBUG=0" \


application does nut run in release mode.

Debug settings should not be changed in this patch.

dehnhardt · 2021-02-05T14:57:53Z

Source/MIDI/CtrlrMIDIDevice.cpp

 #include "CtrlrLog.h"

-CtrlrMIDIDevice::CtrlrMIDIDevice(CtrlrMIDIDeviceManager &_owner, const int idx, const String name, const bool type)
+CtrlrMIDIDevice::CtrlrMIDIDevice(CtrlrMIDIDeviceManager &_owner, const int idx, const String name, const String identifier, const bool type)


The identifier is needed to open the port

dehnhardt · 2021-02-05T14:58:49Z

Source/MIDI/CtrlrMIDIDeviceManager.cpp

 {
-//	inDevs.clear();
-//	outDevs.clear();
+	inDevs.clear();


Why not clearing this way?

keinstein

I think you should split the patch into 3 parts: MIDI, Linux and Debug.

keinstein · 2021-02-11T15:28:19Z

.gitignore

+Packaging/**
+.vscode/**
+Source/Core/stdafx_luabind.h.gch
+Source/Core/stdafx.h.gch


This is only Windows related and should be removed from the patch

keinstein · 2021-02-11T15:29:17Z

Builds/LinuxMakefile/build.sh

 	echo "stadfx.h"
-	g++  -w -std=c++14 -D "LINUX=1" -D "NDEBUG=1" \
-		-D "JUCE_FORCE_DEBUG=0" -D "CTRLR_NIGHTLY=1" \
+	g++  -w -std=c++14 -D "LINUX=1" -D "NDEBUG=0" \


Debug settings should not be changed in this patch.

keinstein · 2021-02-11T15:30:31Z

Builds/LinuxMakefile/build.sh

+make CONFIG=Debug -j$MAXJOBS
 if [ $? -ne 0 ]; then
 	echo -e "CTRLR[linux]: build failed\n"
 	exit 1


A patch that fixes a particular issue should not contain anything else, especitally debug or non-debug.

keinstein · 2021-02-11T15:31:58Z

Source/Core/CtrlrRevision.h

-static const char *ctrlrRevision              	= "5.6.0";
-static const char *ctrlrRevisionDate        	= "Wed, Jan 27, 2021  3:40:04 PM";
-
-#endif


Is the version change necessary? Are you shure, that you want to step by two ?

keinstein · 2021-02-11T16:44:20Z

Builds/LinuxMakefile/Makefile

 	-$(V_AT)mkdir -p $(JUCE_VSTDESTDIR)
 	-$(V_AT)cp -R $(JUCE_COPYCMD_VST)

-$(JUCE_OUTDIR)/$(JUCE_TARGET_VST3) : $(OBJECTS_VST3) $(RESOURCES) $(JUCE_OUTDIR)/$(JUCE_TARGET_SHARED_CODE)


yes

But I'd think this is a bug in Projucer

dehnhardt · 2021-02-11T17:00:47Z

I think you should split the patch into 3 parts: MIDI, Linux and Debug.

As I said in the notes on the top, this PR was not intended to be applied, because still some things doe not work. I had no time to dig deeper into that, I just did not want to throw away my findings.
Related to the debug settings: Strangely, the application only runs when I do a debug build. With a release build, it crashes as soon as I open a panel. Therefore, they somehow already belong in this patch ;-)

mtarenskeen · 2021-03-22T10:31:31Z

My coding skills are too limited to contribute much, but following this issue with interest.
I would love to see a reliable stable new Linux build. Just one request: Ubuntu is very popular, but Linux is more than just Ubuntu. Would be nice if the build scripts will work on other Linux distributions as well.

keinstein · 2021-05-01T08:11:36Z

Could you please try current master? Some of my changes have been merged.

make it compile and work

2b8a024

dehnhardt commented Feb 5, 2021

View reviewed changes

Possemo mentioned this pull request Feb 7, 2021

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

Open

keinstein reviewed Feb 11, 2021

View reviewed changes

RomanKubiak force-pushed the master branch 4 times, most recently from 9eacd2a to d4a15a8 Compare June 20, 2022 16:17

keinstein mentioned this pull request Nov 13, 2022

Opening MIDI devices on Linux always fails. Fix inside #492

Open

Uh oh!

Conversation

dehnhardt commented Feb 5, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keinstein left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dehnhardt commented Feb 11, 2021

Uh oh!

mtarenskeen commented Mar 22, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

keinstein commented May 1, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mtarenskeen commented Mar 22, 2021 •

edited

Loading