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.
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 !)
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!!! 
Added "cableColors" property to settings.json.
3 Likes