Rack v1 development blog

New modules are placed where you drag them.

I see. I guess I still miss being able to drop a new module with the keyboard (Enter) after a search like in v0.6. I use that quite a bit, especially when playing live and patching on the fly. I place my mouse where I want the module, open the module browser with Enter, type the module name and confirm placement with Enter, then use the track pad for wires. This is just a little different and takes some getting used to.

1 Like

Many dependencies have been updated. You will have the best luck wiping the repo and checking it out again. Or you could try

git pull
cd dep
make clean

# You might even want to remove all the folders here
rm -rf rtmidi glfw nanovg nanosvg

git submodule sync
git submodule update --init
make -j8

cd ..
make -j8

I’m having a small problem with the glfw dependency (https://github.com/VCVRack/Rack/issues/1263)
EDIT: fixed by a new commit

Cable ports are now rendered under wires.
2019-04-29-181527_1600x900_scrot
This draw order is not flawless, however. See the bottom green cable.

2 Likes

My guess for ETA is

  • Stable v1 API: May 7-14
  • Stable v1 ABI: June 1-14
  • Release of v1: June 1-14
22 Likes

Cable drag (individual tension) could probably help those who find that behaviour upsetting.

Vortigo wrote:
Release of v1: June 1-14

How this will work?
One morning all the 0.62c files are gone and there are only the 1.0 files to download?

Are the 0.62c files on a backup / archive side?
Should we have a second computer for 1.0 first?

Or could the 0.62c and 1.0 be used on one computer? Think not, because of the plugin confusion?

it would be really cool, if there were an update to v0.6 that uses a “My Documents”/Rack0.6 folder
then v1.0 can use the “My Documents”/Rack folder
jm2c

You can do that already by specifing command line parameters, using both versions side-by-side is not a problem.


Also, this conversation is going offtopic…

1 Like

After the full update I’m having problem with linking with librtmidi.a and librtaudio.a

I know that is irrelevant on the main build system, but I have a parallel build based on XCode that is failing linking to both libs because of

Undefined symbols for architecture x86_64:

for example

Undefined symbols for architecture x86_64:
“_AudioConvertHostTimeToNanos”, referenced from:
midiInputCallback(MIDIPacketList const*, void*, void*) in librtmidi.a(librtmidi_la-RtMidi.o)

the main difference is that before we were using dynamic linking libs and now we have static libs

if I recompile rtmidi using

./configure --prefix="/Users/mysys/Desktop/githubprojects/Rack100/dep/." --enable-shared=yes --with-jack=no

and rtaudio using

cmake -DCMAKE_INSTALL_PREFIX="/Users/mysys/Desktop/githubprojects/Rack100/dep/." -DCMAKE_INSTALL_LIBDIR=lib -DRTAUDIO_BUILD_STATIC_LIBS=OFF -DRTAUDIO_API_CORE=ON -DRTAUDIO_API_PULSE=OFF -DRTAUDIO_API_JACK=OFF …

everything is fine

RtAudio and RtMidi have been statically linked for a while. What’s your MacOS version?

Mac OSX High Sierra 10.13.4
XCode 9.4.1

for more informations

I did a LIPO on both static libs and they are indeed x86_64 (and I did some LIPO on the “.o” files too and they are x86_64 too)

If I exclude them from building, I have “missing 9 linking symbols”
If I include I have 38 wrong symbols (for the x86_64 missing )

if I have in the same directory the dylib (but not included in the project) and the static but included
I have no errors ( bizarre !)

09

Oh, I see. You’re trying your own build system. Yeah, can’t help you there.

1 Like

Wohooo… is it Ok to just be exited as a little kid for a moment? V1 promises a lot of awesome features, can’t wait. Thanks for all your hard work Andrew!

7 Likes

I agree! I check this thread almost daily! SUPER excited for V1!

2 Likes

I think it will be very usefull and needed for all the users, that are not developers,
to have step-by-step instructions on how to do this

3 Likes

Oooh! My birthday is June 12th!!! :birthday:

Added "cableColors" property to settings.json.

3 Likes