[shooking]

thats what I am doing now.

function processMulti(--[[ CtrlrMidiMessage --]] midiMessage,
        --[[ bool --]] singlePatch )
    console("in processMulti")
-- single and multiple transfers have similar initial header
-- CHECK ... 
    if validateSysexHeader(midiMessage, singlePatch) == false then
        console("invalid sysex header")
        return
    end

    if singlePatch == true then
        local size = midiMessage:getSize()
        local patch = midiMessage:getData():getByte(7)
        -- so patch - 64 is the multi we want to update LCD
        patch = patch - 64
        local d = midiMessage:getData()
        local lp
        -- skip the F0 -- first 8 bytes and we dont and the F7
        for lp=0, size - 8 - 1 do
            g_multiPatch[patch]:setByte(lp, d:getByte(lp+8))
        end

        console(string.format("Single %d", size))
        -- we dont want the trailing F7
        process_one_multi( patch, g_multiPatch[patch], g_multiPatch[patch]:getSize() )
    else
        console("BULK")
        -- so we know we have a validSysex
        -- then 32 blocks of patch data.
        -- finally a checksum
        -- check because it ISNT 32 full single size sysex
        -- one sysex head, 32 blocks, one checksum on end byte
        local i, lp
        local singleSize=76
        for i=0, 31 do
            local d = midiMessage:getData():getRange(8 + 
                        i*(singleSize), 8 + (i+1)*(singleSize))
            for lp=0, singleSize do
                g_multiPatch:setByte(lp, d:getByte(lp))
                -- we dont want the trailing F7
            end
            process_one_multi( i, g_multiPatch,  singleSize )
        end 
    end

I was a PITA to work out

  g_multiPatch = {}
    -- let store it as 32
    -- note 76 data -- strip of Sysex Header and F7
    for i = 0, 31 do
        g_multiPatch = CtrlrLuaMemoryBlock(76, true)
    end

these “blocks” start a 0 🙂
I not managed to the CopyTo working consistently

x = CtrlrLuaMemoryBlock(85, true)
console(string.format("%d", x:getSize()))
for i=1,85 do y:setByte(i, i) end
CtrlrLuaMemoryBlock::getByte position: 85 is beyond bounds of this memory block with size: 85

-- ok so 0, n-1
for i=0,84 do y:setByte(i, i) end
y:copyTo(x, 0, 85) -- works
-- but midiMessage isnt behaving like a y :-(

I will check out your panels.
I find as I get older if I cannot see it on the screen I’ve already forgot.

The main point of my post was “Is anyone else using the CustomIndex to allow LUA to manipulate positioning / morphing”. As you saw I took a uiSlider and changed it into a uiImageSlider … all with a few lines of LUA … I love gvim and macros but what I did takes this to a new level of lazy 🙂

[shooking]

the 32 LCDs on top (IA1 – IA8, IB1, …, ID1 ID8) represents the 32 available multi slots.
The idea is to bulk load, populate (the Updating button is there to do that). I am just looking for how to pre-allocate space for them on load.

Then double clicking on either of them will bring up the “display” of that Multi (it is 8 horizontal channels). Alas the K1r doesnt allow sysex param manipulation of the multi – you have to modify it and upload.

I _think_ I hear the multi change if I edit an individual Single patch on the correct channel – more as I find it.

Then I want to “Mouse over” to update display based on “in memory” value of the given multi.

So
1] bulk load
2] double click individual multi to request from K1r and “see it”
3] move over to see that one from cache

the sysex to the K1r is, on mine at least, suspect.
I can trigger from the K1r direct and I see the result in the panel.
I can see sysex is being send via midi monitor – K1r refused to reliably talk to me – I can understand that.

Ultimately I want to rework my K1r Single panel and do a similar thing to visualize any of the 64 singles.

[shooking]

and see I found an excellent novation panel with image buttons.
So I have borrowed the knobs.
Imported the resource.

Dang I want to change all my transpose knobs … wont that be a tedious set of clicking or XML editing.
Screw that

local i
local x
local y
local name
local basename="Tran"
local m
local sName
local rect
for i=1, 8 do
	name=basename..string.format("%02d", i)
-- 1000+i
	m = panel:getModulatorWithProperty("modulatorCustomIndex",9000+i)
	sName = m:getName()
	m:setPropertyString("name", name)
	m:getComponent():setPropertyString("componentVisibleName", name)
	x = math.floor((i - 1) % 8)
	y = math.floor((i - 1) / 8)
	rect = string.format("%d %d %d %d", x*100, 264 + y*16, 48, 40)
	console(rect)
	m:getComponent():setPropertyString("componentRectangle",rect)
	m:getComponent():setPropertyString("uiImageSliderResource","xstation_bidirect_64x64")
	m:getComponent():setPropertyString("resourceImageWidth", "64")
	m:getComponent():setPropertyString("resourceImageHeight", "64")
	m:getComponent():setPropertyString("resourceImagePaintMode", "36")
	m:getComponent():setPropertyString("resourceImageOrientation", "1")
	m:getComponent():setPropertyString("uiType", "uiImageSlider")
	m:getComponent():setPropertyString("uiSliderStyle", "RotaryVerticalDrag")
	m:getComponent():setPropertyString("componentLabelPosition", "top")
	m:getComponent():setPropertyString("componentLabelJustification", "centred")
	sName = m:getName()
	console(sName)
end

here’s the effect .. repeat for the others, just modify my coords, my base name.
Notice I am changing the component type .. recall to save your original to one side incase you foobar.
And recall to close and reopen the panel to see the effects.
Notice I moved the position of the labels – just look at the Utility, cut and paste into a notepad
Examine the fields you want to change … do it.

Attachments:

You must be logged in to view attached files.

[shooking]

whats best way to achieve that – can they just be included in one of these threads?
The panel would only show the output – the LUA was run from console and stored in a Notepad++

You see from the capture repeated “stuff”.
Each row (and 8 x 4 matrix of LCDs at top) are given unique sequential custom ids

Then I simply write LUA to position them where I want.

If I dont like it, no problem – write another deployment algorith,
Before I did this by editing XML.

Attachments:

You must be logged in to view attached files.

[shooking]

Yes. Please see http://ctrlr.org/forums/topic/is-there-a-kawai-k1r-panel/

[shooking]

Hi Ryan
The detailed write up for RPI is above already. It will build a standalone. VST fails becasee the makefile doesn’t point to right source (Linux fails, windows works).

Use {} around the environment variables – I realise I typed in makefile format.

I aim to writeup cross compiler. I tested in 32bit too – MUCH faster than 64bit but it was 6.2 g++. This requires some source code modification.

Ideally I would love to collabotare with Atom so as to check some changes into git rather than separate branch.

From my perspective I simply wanted a build on Pi and I have this now. But I have windows, Linux, RPI and now iOS envs so could help on any platform.

[shooking]

Success. Managed to get cross compile to build.
Will write this up at weekend. The biggest issue was forgetting that if one rsync -l then the symlinks are preserved … but changes your host will find target files to those links is 0% – hence the link failures. There’s a little bit more to it than that but really happy with the results. Javi will help me configure a Mac emulator soon too.

Compiling CtrlrManagerWindowManager.cpp
Compiling CtrlrPanelWindowManager.cpp
Compiling BinaryData.cpp
Compiling juce_audio_basics.cpp v0
Compiling juce_audio_basics.cpp
Compiling juce_audio_devices.cpp
Compiling juce_audio_formats.cpp
Compiling juce_audio_processors.cpp
Compiling juce_audio_utils.cpp
Compiling juce_core.cpp
Compiling juce_cryptography.cpp
Compiling juce_data_structures.cpp
Compiling juce_events.cpp
Compiling juce_graphics.cpp
Compiling juce_gui_basics.cpp
Compiling juce_gui_extra.cpp
Compiling juce_opengl.cpp
Linking Ctrlr_Standalone
../build/arm/lua_422403e.o: In function `os_tmpname’:
lua.c:(.text+0xf3ac): warning: the use of tmpnam' is dangerous, better usemkstemp’
CTRLR[arm]: build succeeded

CTRLR: Clean old package files
CTRLR: copy files for package
cp: cannot stat ‘/home/shooking/Documents/ctrlr/Scripts/..//Bin/libCtrlr-*’: No such file or directory
CTRLR: create self extracting package
Header is 402 lines long

About to compress 30452 KB of data…
Adding files to archive named “/home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh”…
./
./Doc/
./Doc/ctrlr_red.ico
./Doc/ctrlr_black.xcf
./Doc/lua.txt
./Doc/Ctrlr.overrides
./Doc/Licenses/
./Doc/Licenses/LCDWinTT/
./Doc/Licenses/LCDWinTT/LICENSE.TXT
./Doc/Licenses/LCDWinTT/README.TXT
./Doc/Licenses/Digital-7/
./Doc/Licenses/Digital-7/README.TXT
./Doc/Licenses/69sekuntia/
./Doc/Licenses/69sekuntia/readme.txt
./Doc/Licenses/LCDMonoWinTT/
./Doc/Licenses/LCDMonoWinTT/LICENSE.TXT
./Doc/Licenses/LCDMonoWinTT/README.TXT
./Doc/ctrlr.doxygen
./Doc/gpl.txt
./Panels/
./Ctrlr-arm
CRC: 3797406403
MD5: f073962a6ec26995c44607a771cd019e
/home/shooking/Documents/ctrlr/Scripts/..//Packaging/RPI3/makeself.sh: 1: /home/shooking/Documents/ctrlr/Scripts/..//Packaging/RPI3/makeself-header.sh: cannot create /home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh: Directory nonexistent
/home/shooking/Documents/ctrlr/Scripts/..//Packaging/RPI3/makeself.sh: 1: eval: cannot create /home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh: Directory nonexistent
/home/shooking/Documents/ctrlr/Scripts/..//Packaging/RPI3/makeself.sh: 197: /home/shooking/Documents/ctrlr/Scripts/..//Packaging/RPI3/makeself-header.sh: cannot create /home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh: Directory nonexistent

/home/shooking/Documents/ctrlr/Scripts/..//Packaging/RPI3/makeself.sh: 403: /home/shooking/Documents/ctrlr/Scripts/..//Packaging/RPI3/makeself.sh: cannot create /home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh: Directory nonexistent
chmod: cannot access ‘/home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh’: No such file or directory
Self-extractible archive “/home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh” successfully created.
CTRLR: # scp, key: /home/shooking/Documents/ctrlr/Scripts/..//Packaging/ctrlr.key, pkg: /home/shooking/Documents/ctrlr/Scripts/..//Packaging/arm/Ctrlr-armv7l-5.4.3.sh, out: ctrlrorg@ctrlr.org:/home/ctrlrorg/public_html/nightly/
CTRLR: private key not specified, using defaults

real 95m4.790s
user 173m2.720s
sys 8m25.320s
shooking@shookingVB:~/Documents/ctrlr/Scripts$ cd ../Packaging/
shooking@shookingVB:~/Documents/ctrlr/Packaging$ ls
Linux Mac RPI3 Windows
shooking@shookingVB:~/Documents/ctrlr/Packaging$ cd RPI3/
shooking@shookingVB:~/Documents/ctrlr/Packaging/RPI3$ ls
Ctrlr makeself-header.sh makeself.sh
shooking@shookingVB:~/Documents/ctrlr/Packaging/RPI3$ ls -l
total 28
drwxr-xr-x 4 shooking shooking 4096 Jan 5 20:49 Ctrlr
-rwxr-xr-x 1 shooking shooking 9635 Jan 3 14:27 makeself-header.sh
-rwxr-xr-x 1 shooking shooking 11923 Jan 3 14:27 makeself.sh
shooking@shookingVB:~/Documents/ctrlr/Packaging/RPI3$ cd Ctrlr/
shooking@shookingVB:~/Documents/ctrlr/Packaging/RPI3/Ctrlr$ ls
Ctrlr-arm Doc Panels
shooking@shookingVB:~/Documents/ctrlr/Packaging/RPI3/Ctrlr$ file Ctrlr-arm
Ctrlr-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=81026fea0affe581d36d22baa84fe66e750ab6aa, not stripped
shooking@shookingVB:~/Documents/ctrlr/Packaging/RPI3/Ctrlr$ ./Ctrlr-arm
bash: ./Ctrlr-arm: cannot execute binary file: Exec format error

Attachments:

You must be logged in to view attached files.

[shooking]

And, using my friend Javi’s Official RPi Touchscreen it works!

The TS is running at 800×480 – I normally try to design my panels to work at 1280×800 so will be looking for a larger touch display. But it is more than usable.
Javi explained that /boot/config.txt needs to have the following modification:

lcd_rotate=2

the rotary sliders work particularly well, as does the combo boxes.
I will need to move my sliders further apart and use multiple tabs if I stay at the 800×480 resolution.

Here’s a picture of combo selection.

Attachments:

You must be logged in to view attached files.

[shooking]

`So I managed to get the cross compiler to nearly work on Ununtu x86_64.
Just having a few snags with libraries.
I modified your build scripts to look for 2nd argument RPI3 and if so create a cross compiled build.

As it stands the link failed BUT the basic compilation is at least 4x faster.
This allows me to rsync the *.o/*.d files to RPI and finish the link there (provided I create a similar phantom /opt/RPI3/ env as on the host machine).

I will try to get the process working fully before i publish what I did, but it is the normal “download cross compile package, modify the CC/CXX/LDm, make some changes to the -I/-L paths and modify the post-commmit/build.sh/Makefile)

Regards
Steve H

PS had some problems loading some bzpanels on my build but mostly all the panels I have tried seem to work. Now looking for a decent / large Pi compatible touch screen.

[shooking]

Hi Atom

SOLVED! I rebuilt on Linux (using the checkout method) and hit the same issue. BUT I removed the “strip” commands from post-commit so I could debug. And found the zenity was causing issues – and that when I found this is a known issue with Linux rather than Ctrlr (see http://ctrlr.org/forums/topic/zenity-fileselector-freezes-my-panel/)

Anyhow the RPi3 can now load my K4 panel — off to test it with MIDI cable etc.

I will try to work out what magic I need to fix the VST build – the good news is I am compiling on fast laptop with Ubuntu in VM so I can make lots of builds and then test on RPi when I am sure the Linux builds fine.

You asked what problems I face?

The current git only seems to work for Windows.
I understand you are primarily working on Windows and will then work on the other platforms. If there is anything I can do to assist please let me know. For example, should I try to reverse engineer the file locations you use in Windows in the “latest” build for Linux? I see you have added boost into Misc subdir now. As you said, if you are ditching Projucer for make etc then for sure I can help. Off to play with Pi – I really thank you for all your work.

Regards
Steve Hookings

[shooking]

Great. If I can help in any way (testing, building etc) please let me know. My personal wish is to get this working on Pi but I have Ubuntu and VS machines etc.

I am running your code thru snavigator so I can get a better idea of what it is doing. Also I aim to get gdb on it to see if I can work out why my build hangs.

Thanks again for all your work on Ctrlr. Really cool stuff.

regards
Steve H

PS you got my litle daughter vaguely interested in helping me with computers – normally that’s tricky for me!

[shooking]

USE UBUNTU MATE ON PI

(And if you get this to build please consider tipping Martin Wimpress for the hard work his team done on Ubuntu Mate!)
UBUNTU MATE RPI2 or 3

WARNING – ALAS – The build works but freezes if I try to load a panel.
I will be debugging this.

0 – Get yourself the fasted card you can buy (see why later)
You will need about 3GB of extra space for source, build and swap
1 – I installed Ubuntu Mate
Will try with Raspbian IF I get time.
2 – I updated/upgraded
3 – I resized the partitions
4 – I installed git and vim

GET THE LATEST CODE

5 – get the archive

CTRLR_ROOT=~/Documents/Software/ctrlr
mkdir -p $(CTRLR_ROOT)
cd ..
git clone https://github.com/RomanKubiak/ctrlr.git

INSTALL THE PACKAGES

In the latest revision of post-commit script (ctrlr/Scripts/post-commit)

UBUNTU_PACKAGES="g++ libxrandr-dev libxinerama-dev libxcursor-dev \
libasound2-dev binutils-dev \
libfreetype6-dev xorg-dev \
libgl1-mesa-dev libglapi-mesa \
libxrandr-dev libudev-dev libgl1-mesa-dev"

so we need to ensure we have these packages

for pack in g++ \
libxrandr-dev \
libxinerama-dev \
libxcursor-dev \
libasound2-dev \
binutils-dev \
libfreetype6-dev \
xorg-dev \
libgl1-mesa-dev \
libglapi-mesa \
libudev-dev
do
sudo apt-get install $pack
done

SET CODEBASE BACK TO WHEN LINUX BUILD CLEAN – WINDOWS DEV CONTINUES TO WORK

6 – grab a timestamped version of the code (thanks to Archangel for hints)

cd ctrlr
git checkout 3d8651d991d377f7b167806c39c47a3121fe9536

ADD SWAP TO YOUR RASPBERRY PI – IT WILL NOT COMPILE WITHOUT THIS

7 – dont forget to add a swap because the compiler needs more than 1gb

sudo dd if=/dev/zero of=/root/myswapfile bs=1M count=2048
sudo chmod 600 /root/myswapfile
sudo mkswap /root/myswapfile

sudo swapon /root/myswapfile

NOTE: add back the swap after reboot. You can probably store this in fstab somewhere?

8 – MODIFY THE BUILD SCRIPT

NOTE: the post-commit calls out to build.sh and Makefile.
There are two build.sh (relative to your ctrlr root):

cd $CTRLR_ROOT
find . -name "build.sh" -print
./Builds/Generated/Linux/VST/build.sh
./Builds/Generated/Linux/Standalone/build.sh

and 3 Makefiles – of which ingore the “lo” one

find . -name "Makefile" -print
./Source/Misc/include/lo/Makefile
./Builds/Generated/Linux/VST/Makefile
./Builds/Generated/Linux/Standalone/Makefile

If you simply run it from this point, it will fail as below:

$(CTRLR_ROOT)/Scripts/post-commit

...
 inflating: boost/lambda/casts.hpp
  inflating: boost/lambda/control_structures.hpp
  inflating: boost/lambda/switch.hpp
  inflating: boost/lambda/lambda.hpp
CTRLR: Build Standalone
CTRLR[linux]: Building for arm, JOBS 1
CTRLR[linux]: Compile PCH
In file included from ../../../../Source/Core/stdafx.h:79:0:
../../../Standalone/JuceLibraryCode/JuceHeader.h:18:49: fatal error: juce_audio_basics/juce_audio_basics.h: No such file or directory
 #include <juce_audio_basics/juce_audio_basics.h>

^
compilation terminated.

WHY DOES THE BUILD FAIL?

And it turns out there is a bug in the make file. We need to fix
some paths for includes etc.

— ADD IN Juce/modules to BOTH build.sh (see code snippet below)

we had to change build.sh as follows:

if [ "$1" == "-f" ]; then
        echo "CTRLR[linux]: Compile PCH"
        g++  -std=c++0x -D "LINUX=1" -D "NDEBUG=1" -D "JUCE_FORCE_DEBUG=0" -D "CTRLR_NIGHTLY=1" -D "JucePlugin_Build_Standalone" -D "LUA_USE_LINUX" -D "_LINUX=1" -D "JUCER_LINUX_MAKE_CC96CACF=1" -I /usr/include -I /usr/include/freetype2 -I ../../../Standalone/JuceLibraryCode -I../../../../Juce/modules -I ../../../../Boost -I ../../../../Source/Lua/luabind -I ../../../../Source/Misc -I ../../../../Source/MIDI -I ../../../../Source -I ../../../../Source/UIComponents -I ../../../../Source/Core -I ../../../../Source/Plugin -I ../../../../Source/Application -I ../../../../Source/Lua -I ../../../../Source/Lua/lua -march=native -Os -fpermissive -o "../../../../Source/Core/stdafx.h.gch" -c "../../../../Source/Core/stdafx.h"
else

WAIT FOR IT – SOME LIBRARIES NEED TO BE COPIED
SOME NEED TO BE INSTALLED
ON UBUNTU MATE the correct naming is arm.
FIND some files

sudo find / -name libbfd.a -print
find: ‘./run/user/1000/gvfs’: Permission denied
./usr/lib/arm-linux-gnueabihf/libbfd.a

hence

cp /usr/lib/arm-linux-gnueabihf/libbfd.a $(CTRLR_ROOT)/Builds/Generated/Linux/Standalone/libbfd-arm.a
cp /usr/lib/arm-linux-gnueabihf/libbfd.a $(CTRLR_ROOT)/Builds/Generated/Linux/VST/libbfd-arm.a

CLEAN UP SOME PACKAGES

sudo apt autoremove

GOOGLE to find where libiberty comes from

libiberty-dev
So we use

sudo apt-get install libiberty-dev
sudo find / -name 'libiberty*' -print
find: ‘./run/user/1000/gvfs’: Permission denied
./var/lib/dpkg/info/libiberty-dev:armhf.list
./var/lib/dpkg/info/libiberty-dev:armhf.md5sums
./var/cache/apt/archives/libiberty-dev_20160215-1_armhf.deb
./usr/lib/arm-linux-gnueabihf/libiberty.a
./usr/include/libiberty
./usr/include/libiberty/libiberty.h

cp /usr/lib/arm-linux-gnueabihf/libiberty.a $(CTRLR_ROOT)/Builds/Generated/Linux/Standalone/libiberty-arm.a
cp /usr/lib/arm-linux-gnueabihf/libiberty.a $(CTRLR_ROOT)/Builds/Generated/Linux/VST/libiberty-arm.a

And with the above

cd $(CTRLR_ROOT)/Scripts
./post-commit

and it will build in about 5 hours for standalone. VST fails at the moment

CTRLR[linux]: Building for arm, JOBS 1
CTRLR[linux]: Compile PCH
CTRLR[linux]: Remove the shared source, for main() compatibility
CTRLR[linux]: Build now

Compiling CtrlrOSC.cpp
Compiling CtrlrUtilitiesGUI.cpp
Compiling CtrlrSysexProcessorOwned.cpp
Compiling CtrlrFontManager.cpp
Compiling CtrlrIDManager.cpp
Compiling CtrlrLog.cpp
Compiling CtrlrManager.cpp
Compiling CtrlrManagerInstance.cpp
...
Compiling BinaryData.cpp
Compiling juce_audio_basics.cpp
Compiling juce_audio_devices.cpp
Compiling juce_audio_formats.cpp
Compiling juce_audio_processors.cpp
Compiling juce_audio_utils.cpp
Compiling juce_core.cpp
Compiling juce_cryptography.cpp
Compiling juce_data_structures.cpp
Compiling juce_events.cpp
Compiling juce_graphics.cpp
Compiling juce_gui_basics.cpp
Compiling juce_gui_extra.cpp
Compiling juce_opengl.cpp
Linking Ctrlr_Standalone
CTRLR[linux]: build succeeded

NOTE: DONT PANIC – You poor Pi will freeze … many times.
It is paging and swapping.
The PCH phase takes about 15 mins.
Then each file takes about 1 minutes 20 seconds on a Pi3.
Do the math – N files x 4/3 ~

shooking@CharPi:~/Documents/Software/ctrlr/Builds/Generated/Linux/Standalone$ grep "\$(OBJDIR)" Makefile | grep -v mkdir | grep -v "\.\." | wc -l
224

(224-3) x 4/3 ~ 222 x 4 / 3 = 74 x 4 = 296 minutes or around 5 hours.

PLEASE use the fastest uSD card you can get. Mine is a Samsung EVO.
£22 for 64GB. With a class 10 I would imagine the build could take a day!
BETTER if you can use a SSD drive.
The MS 2015 build is almost instantaneous in comparison.
And that is with 2GB RAM, the other 4GB used on an Ubuntu VM that allowed me to get the Linux build working.

ALAS – The build works but freezes if I try to load a panel.
I will be debugging this.

THANKS to

1. Atom for bringing us Ctrlr
2. Archangel for tips on git timestamps
3. Martin Wimpress and team for bringing us Ubuntu Mate on Pi
4. My kleiner Tochter Charlotte for checking / debugging build.sh with me

Anyone who can get past the lack of Open — would appreciate some hints.

Attachments:

You must be logged in to view attached files.

[shooking]

Hi
Regarding your Atari ST (you make me pine for mine that died years ago!).
Can you hook the midi out to a Windows PC midi in.
And the Windows PC midi out to Atari ST Midi in.
Then download and use MidiOX to watch the midi generated by ST.
And send some strings from the PC to see if the Atari faithfully responds (it should).

This will allow you to see what your ST midi apps are generating and hence what to replicate on Ctrlr or on the BCR.

If you are serious about BCR then I would suggest Mountain Utilities BCR editor. Please donate to Mark if you like it! Using his software allowed me to quickly generate BCR panels for AKAI Miniak. Without it I would have gone crazy. There again once I found some folks generated panels for Miniak in Ctrlr I caught the bug and created some K1r/K4 panels.

[shooking]

OK so I managed to compare the Windows build process with Raspberry Pi.
I would love to know what creates these files:

# Automatically generated makefile, created by the Projucer
# Don’t edit this file! Your changes will be overwritten when you re-save the Projucer project!

But I had to pull down Lua 5.3, ln -s it to the correct place.
Similarly with some other files and/or modify the build.sh

I can build pretty much all of the targets on Pi now. Sure will work on cross compiler for speed – fortunately I was busy on other stuff tonight so I could leave the pi chugging away.

Anyhow now I need to work on the link phase now – missing references.

JUCE_CXXFLAGS += $(CXXFLAGS) $(JUCE_CFLAGS) -std=c++11
JUCE_LDFLAGS += $(LDFLAGS) $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) -L/usr/X11R6/lib/ -lGL -lX11 -lXext -lXinerama -lasound -ldl -lfreetype -lpthread -lrt libbfd-$(ARCH).a libiberty-$(ARCH).a -lz -lGL -ludev

I am getting things like:

CTRLR[linux]: Building for arm, JOBS 1
CTRLR[linux]: Compile PCH
./build.sh: line 29: 24522 Aborted g++ -std=c++0x -D “LINUX=1” -D “NDEBUG=1” -D “JUCE_FORCE_DEBUG=0” -D “CTRLR_NIGHTLY=1” -D “JucePlugin_Build_Standalone” -D “LUA_USE_LINUX” -D “_LINUX=1” -D “JUCER_LINUX_MAKE_CC96CACF=1” -I /usr/include -I /usr/include/freetype2 -I ../../../Standalone/JuceLibraryCode -I ../../../../Juce/modules -I ../../../../Boost -I ../../../../Source/Lua/luabind -I ../../../../Source/Misc -I ../../../../Source/MIDI -I ../../../../Source -I ../../../../Source/UIComponents -I ../../../../Source/Core -I ../../../../Source/Plugin -I ../../../../Source/Application -I ../../../../Source/Misc/include -I ../../../../Source/Lua -I ../../../../Source/Misc/liblo/include/lo -march=native -Os -fpermissive -o “../../../../Source/Core/stdafx.h.gch” -c “../../../../Source/Core/stdafx.h”
CTRLR[linux]: Remove the shared source, for main() compatibility
CTRLR[linux]: Build now

Linking Ctrlr_Standalone
build/intermediate/Release_Nightly/loslib_f291a7f9.o: In function `os_tmpname’:
loslib.c:(.text+0x224): warning: the use of tmpnam' is dangerous, better usemkstemp’
build/intermediate/Release_Nightly/LAudio_a50e2b40.o: In function `int luabind::detail::ref_converter::match(lua_State*, luabind::detail::by_reference, int) [clone .isra.625]’:
LAudio.cpp:(.text+0x84): undefined reference to `luabind::detail::get_instance(lua_State*, int)’
build/intermediate/Release_Nightly/LAudio_a50e2b40.o: In function `int luabind::detail::ref_converter::match(lua_State*, luabind::detail::by_reference, int) [clone .isra.649]’:
LAudio.cpp:(.text+0x118): undefined reference to `luabind::detail::get_instance(lua_State*, int)’
build/intermediate/Release_Nightly/LAudio_a50e2b40.o: In function `int luabind::detail::ref_converter::match(lua_State*, luabind::detail::by_reference, int) [clone .isra.659]’:
…

enums.c:(.text+0x1788): undefined reference to `luaL_typerror’
enums.c:(.text+0x17a8): undefined reference to `luaL_typerror’
enums.c:(.text+0x17c0): undefined reference to `lua_tonumber’
enums.c:(.text+0x17d8): undefined reference to `lua_tonumber’
build/intermediate/Release_Nightly/enums_78c5918.o: In function `luausb_to_transfer_status’:
enums.c:(.text+0x18c0): undefined reference to `lua_tonumber’
enums.c:(.text+0x18d8): undefined reference to `lua_tonumber’
build/intermediate/Release_Nightly/enums_78c5918.o: In function `luausb_check_transfer_status’:
enums.c:(.text+0x19f4): undefined reference to `luaL_typerror’
enums.c:(.text+0x1a14): undefined reference to `luaL_typerror’
enums.c:(.text+0x1a2c): undefined reference to `lua_tonumber’
enums.c:(.text+0x1a44): undefined reference to `lua_tonumber’
collect2: error: ld returned 1 exit status
Makefile:337: recipe for target ‘../../../../Bin/Ctrlr-arm’ failed
make: *** [../../../../Bin/Ctrlr-arm] Error 1
CTRLR[linux]: build failed

I will do some objdump/nm to see if I can work out paths to any libraries etc.

[shooking]

I am struggling to build this from git source on Pi.

1 – I pulled down source to build on Cygwin on laptop … also struggled.
But the Windows Studio worked fine.

At the moment I hacked the post-commit script on Pi to pull down packages 1st time around.

2 – Then I commented it out

function check_pkgs_ubuntu() {
IFS=” ”
for p in $UBUNTU_PACKAGES; do
echo “LOOKING FOR $p”
# sudo apt-get install $p
echo -ne “\t[$p:”
dpkg-query -W $p 2> /dev/null 1> /dev/null
if [ $? -ne 0 ]; then

This script unpacks the boost.zip etc.

However, I also had to hack the script as follows

#if [ “$DISTRO” == “Ubuntu” ]; then
echo “CTRLR: distro detected as $DISTRO, check packages”
check_pkgs_ubuntu
#fi

to prevent it stopping because Pi isnt Ubuntu.

3 – Oh and add in some build info for Linux (I took out the Darwin and Windows cruft) as end

detect_os
build_now

SO that got me pretty much all of the source.

Then I had to edit the build.sh … lots of includes were missing OR maybe there is something the commit script does that I got wrong?

Anyhow steps like

1 – modify the post-commit script to pull down dependencies

2 – modify build.sh to include the Misc/lua/include — including top part!! and 3 more

3 – ln -s the luabind to the right place.

—-

THen I had to give the Pi a bit of swap space — note I have the fastest Samsung Evo+ card. A class 10 would be way too slow IMHO.

sudo fallocate -l 1G tmpswap
sudo mkswap tmpswap
sudo swapon tmpswap

Then we are almost in business

THE BUILD

pi@raspberrypi:~/Software/ctrlr/Builds/Generated/Linux/Standalone $ ./build.sh
CTRLR[linux]: Building for arm, JOBS 1
CTRLR[linux]: PCH not rebuilt, use -f to force
CTRLR[linux]: Remove the shared source, for main() compatibility
CTRLR[linux]: Build now

Compiling CtrlrOSC.cpp
Compiling CtrlrUtilitiesGUI.cpp
Compiling CtrlrSysexProcessorOwned.cpp
Compiling CtrlrFontManager.cpp
Compiling CtrlrIDManager.cpp
Compiling CtrlrLog.cpp
Compiling CtrlrManager.cpp
Compiling CtrlrManagerInstance.cpp
Compiling CtrlrManagerVst.cpp
Compiling CtrlrModulator.cpp
Compiling CtrlrModulatorProcessor.cpp
Compiling CtrlrPanelOSC.cpp
Compiling CtrlrPanelUndoManager.cpp
Compiling CtrlrEvaluationScopes.cpp
Compiling CtrlrPanel.cpp
Compiling CtrlrPanelFileOperations.cpp
Compiling CtrlrPanelMIDIInputThread.cpp
Compiling CtrlrPanelMIDISnapshot.cpp
Compiling CtrlrPanelProcessor.cpp
Compiling CtrlrPanelResource.cpp
Compiling CtrlrPanelResourceManager.cpp
Compiling CtrlrProperties.cpp
Compiling CtrlrSysexProcessor.cpp
Compiling CtrlrSysexToken.cpp
Compiling CtrlrUpdateManager.cpp
Compiling CtrlrUtilities.cpp
Compiling CtrlrStandaloneApplication.cpp
Compiling CtrlrStandaloneWindow.cpp
Compiling stdafx.cpp
Compiling LAudio.cpp
Compiling LComponents.cpp
Compiling LCore.cpp
Compiling LGraphics.cpp
Compiling LJuce.cpp
Compiling LMemory.cpp
Compiling CtrlrLuaDebugger.cpp
Compiling CtrlrLuaAudioConverter.cpp
Compiling CtrlrLuaCustomComponent.cpp
Compiling CtrlrLuaManager.cpp
Compiling CtrlrLuaModulator.cpp
Compiling CtrlrLuaMultiTimer.cpp
Compiling CtrlrLuaObject.cpp
Compiling CtrlrLuaObjectWrapper.cpp
Compiling CtrlrLuaPanel.cpp
Compiling CtrlrLuaPanelCanvas.cpp
Compiling CtrlrLuaPanelCanvasLayer.cpp
Compiling CtrlrLuaPanelEditor.cpp
Compiling CtrlrLuaUtils.cpp
Compiling CtrlrLuaBigInteger.cpp
Compiling CtrlrLuaComponentAnimator.cpp
Compiling CtrlrLuaFile.cpp
Compiling CtrlrLuaMemoryBlock.cpp
Compiling CtrlrLuaRectangle.cpp
make: *** No rule to make target ‘../../../../Source/Lua/luabind/src/luabind.cpp’, needed by ‘build/intermediate/Release_Nightly/luabind_8688111a.o’. Stop.
CTRLR[linux]: build failed

So have to change to lua51compat.cpp leaving *.o the same.

Dang

I have to add some more include files and modify the make script

$(JUCE_OBJDIR)/address_7a9598ba.o: ../../../../Source/Misc/liblo/src/address.c

libusb/include in the -I

-Wno-reorder not valid for C

And finally I get to here

pi@raspberrypi:~/Software/ctrlr/Builds/Generated/Linux/Standalone $ ./build.sh
CTRLR[linux]: Building for arm, JOBS 1
CTRLR[linux]: PCH not rebuilt, use -f to force
CTRLR[linux]: Remove the shared source, for main() compatibility
CTRLR[linux]: Build now

Compiling compat.c
cc1: warning: command line option ‘-Wno-reorder’ is valid for C++/ObjC++ but not for C
Compiling core.c
cc1: warning: command line option ‘-Wno-reorder’ is valid for C++/ObjC++ but not for C
Compiling darwin_usb.c
cc1: warning: command line option ‘-Wno-reorder’ is valid for C++/ObjC++ but not for C
Compiling descriptor.c
cc1: warning: command line option ‘-Wno-reorder’ is valid for C++/ObjC++ but not for C
Compiling enums.c
cc1: warning: command line option ‘-Wno-reorder’ is valid for C++/ObjC++ but not for C
Compiling hotplug.c
cc1: warning: command line option ‘-Wno-reorder’ is valid for C++/ObjC++ but not for C
Compiling io.c
cc1: warning: command line option ‘-Wno-reorder’ is valid for C++/ObjC++ but not for C
Compiling keys.cpp
make: *** No rule to make target ‘../../../../Source/Misc/lapi.c’, needed by ‘build/intermediate/Release_Nightly/lapi_7f139a72.o’. Stop.
CTRLR[linux]: build failed

and at this point I find I dont have the Lua source (I think this is lapi.c).

If someone can help debug this I would appreciate it.

Regards
shooking

[shooking]

Would the build work from the Raspian “Debian” like Rasperry Pi OS?
I did try this a year ago and got stuck. But I had already moved my C++ compiler to 5.3

Would you mind sharing the toolchains/libraries required with the version you use please – or point us to a link.

I would love to use the Pi3 to run Ctrlr – it could mean a panel for every synth 🙂
And of course potential to add in hybrid of hardware and software controllers – as someone already pointed out a touchscreen would be cool especially as the price of relative large screen display is dropping ($99 for 1366 x 768 13.1″).

Thanks again for sharing your progress so far. It’s encouraging.

[shooking]

Yes.
Please look on http://ctrlr.org/forums/topic/kawai-k4k4r-controller-done/page/2/

You can find the link to Miniaktools – I put my panels for K1r and K4 there.
wikter subsequently made some GUI enhancements to the K4.

I wrote the K4 panel to model basic editing (I have not added the multi) – and of course from this I could see how to modify for the k1r. I was going to sell my K1r but after I made the panel I fell in love with it all over again! So much easier to modify on the PC than reach across to the rack and try to interact …

Hope you find them useful. If you find bugs feel free to point them out (be nice!) and I will try to merge them into the panel and give you credit.

Regards
Steve H

[shooking]

Nice … I see you have made the UI much more compact/logical. Excellent work – like I said I am no artist!

I will test this out at the weekend. Pleasure collaborating with you.

regards
Steve H

[shooking]

There’s no problem with MS/LS … this is simply ctrl’s way to represent the number.
If as you say most of the values are 0 … 127 then the MS will never be used.
But infact many of the values (OSC 2, 3, 4) are > 127 so you do need MS/LS.

You are right that I did not modify the values to centre them (ie I left sysex 0 … 100 as is, rather than -50 … 50). The reason for this is simple. I did all this in C++ program and it was tiresome to modify the sysex decode in LUA. Subsequently I found one can use the +bias and -bias method (like I did on the drop-down menus). Still from my perspective the panel was allowing me to control the params so I was happy to do the math in my head.

You are right that for completeness it should be modified.

Thanks for trying the panel.

regards
Steve H

[shooking]

I have created two panels, albeit in Beta form, for K1r and K4.

Please find them both currently hanging off my Miniaktools website.

https://sourceforge.net/projects/miniaktools/files/beta1/

Imaginatively entitled MyK1Panel.panel and MyK4Panel.panel

So far I expose all the parameters and one can send values to the synths.
I have not written systex decoders (yet) to load up state to the panel.
Looking at some existing panels for inspiration. I also wrote a C# panel so maybe I do the decode there first then work out this LUA language.

The Tools->Send Snapshot at least updates the Kawai’s with your current values.

I am colour / artistically challenged – but the key point is the sysex and ranges are mostly correct should you want to take this and collaborate on improving things.

Please share credit, that’s all I ask. Oh and let me know of bugs which I will try to fix.

I there is an official place to store these by all means let me know.

Hope you find them useful — my K1r is being used again after years of sulking in corner of studio. It is being triggered by the K4 via ctrlr 🙂

And the K4 — much more fun to sculpt with panel than using the presets.
I will probably update wave names on K4 soon (at the moment I just use inc/dec).

Regards
Steve H

[Author]

Posts