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
Super appreciative to see this timeline.
When you get the stable v1 API will there be a URL addressable version of Rack-SDK like their is for 0.6.2? Or will you still require a build of the Rack system to build a plugin? (I only ask because in our CI pipeline we use the download of the rack SDK rather than build all of Rack before we build our plugin and it works great!).
Thanks so much.
When the v1 API is stable, I’ll host v1.dev.* builds for all OS’s and the SDK at https://vcvrack.com/downloads/…
3 Likes
Wonderful thank you. We’re starting a project to move the innards of https://surge-synthesizer.github.io into rack modules - right now my code builds both 062 and 10 but our CI pipeline only works 0.6.2. Will be great to have both in our pipeline!
4 Likes
This will make it much easier to test 1.0 plugins for those of us who aren’t developers. Thank you.
1 Like