but why?..
1 Like
Is this how hardare eurorack actually works? I’ve never owned any hardware but i thought the bus was flexible?
1 Like
No, you always have bus cables, usually 6" long.
I tought it would be helpful while rearranging modules because it will indicate how much space is between two mudules.
If the “force” feature is implemented, my idea is unnecessary.
It also won’t work because there are many very narrow modules. Narrower that this standard would allow, I think.
1 Like
Yes, true. I’ve not thought about all the circumstanced before posting. 
In v1 when a module is selected from the module browser it seems the module gets placed wherever the mouse is when the module is selected. I think it should be placed wherever the mouse WAS before the module browser was invoked. I thought that’s how v0.6 works, no?
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