Package Details: carla-bridges-win32-git 6278.975821819-1

Git Clone URL: https://aur.archlinux.org/carla-bridges-win32-git.git (read-only, click to copy)
Package Base: carla-bridges-win32-git
Description: Carla win32 bridge
Upstream URL: http://kxstudio.sf.net/carla
Licenses: GPL2
Conflicts: carla-bridges-win32
Provides: carla-bridges-win32
Submitter: Joermungand
Maintainer: Joermungand
Last Packager: Joermungand
Votes: 8
Popularity: 0.000032
First Submitted: 2014-10-26 21:15 (UTC)
Last Updated: 2022-03-16 08:37 (UTC)

Pinned Comments

Latest Comments

jpcima commented on 2020-11-25 22:02 (UTC)

Can mingw-w64-pkg-config be changed into a makedepend ?

SpotlightKid commented on 2017-12-03 12:51 (UTC)

Please don't push an update if you only updated your build and nothing changed in the PKGBUILD besides version numbers. Same for the 64-bit package.

Joermungand commented on 2017-11-19 12:23 (UTC)

Thanks, falkTX, both 32- and 64-bit bridges updated.

falkTX commented on 2017-11-18 19:22 (UTC)

to maintainer: please remove vstsdk, it's no longer used in the latest version. (vst3 support dropped)

Joermungand commented on 2017-09-11 09:49 (UTC)

Good to know, thanks. Hopefully it’s solved now.

SpotlightKid commented on 2017-09-11 09:17 (UTC)

The error was also due to the missing gcc-multilib dependency. I realized that shortly after writing a comment and consequenntly deleted it again.

Joermungand commented on 2017-09-10 09:11 (UTC)

@progwolff: added in the new version. @SpotlightKid: I received a notification from you on the 29th concerning some linking error. Now I cannot see that comment any more. Shall I take it the error has been solved? I cannot reproduce it.

progwolff commented on 2017-09-07 13:23 (UTC)

Please add gcc-multilib to the make depends.

Joermungand commented on 2017-08-01 14:29 (UTC)

No PKGBUILD update needed. falkTX sorted it out upstream. You can simply reinstall using the current PKGBUILD. I’ve just tested it and can confirm it works.

funkmuscle commented on 2017-08-01 14:23 (UTC)

thanx falkTX. I'll wait for the PKGBUILD update as I don't know how to disable mingw in the code. I've removed everything 'mingw' in the PKGBUILD and still not building so it's best I wait.

falkTX commented on 2017-07-31 20:41 (UTC)

mingw always crashes on there for some reason. disabled that part of the code, should build fine now.

funkmuscle commented on 2017-07-31 16:07 (UTC)

@SpotlightKid: yep me too. make[1]: Leaving directory '/tmp/pamac-build-harv/carla-bridges-win32-git/src/carla-bridges-win32-git/source/jackbridge' make[1]: Entering directory '/tmp/pamac-build-harv/carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_audio_basics' Compiling juce_audio_basics.cpp (32bit) In file included from ../juce_core/juce_core.h:236:0, from juce_audio_basics.h:60, from juce_audio_basics.cpp:42: ../juce_core/maths/juce_NormalisableRange.h: In member function ‘ValueType juce::NormalisableRange<ValueType>::convertFrom0to1(ValueType) const’: ../juce_core/maths/juce_NormalisableRange.h:132:13: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (skew != static_cast<ValueType> (1) && proportion > ValueType()) ^~ ../juce_core/maths/juce_NormalisableRange.h:135:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ return start + (end - start) * proportion; ^~~~~~ In file included from juce_audio_basics.cpp:93:0: buffers/juce_FloatVectorOperations.cpp: In static member function ‘static void juce::FloatVectorOperations::enableFlushToZeroMode(bool)’: buffers/juce_FloatVectorOperations.cpp:1010:1: internal compiler error: in ix86_compute_frame_layout, at config/i386/i386.c:12444 } ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. make[1]: *** [Makefile:87: ../../../build/juce_audio_basics/Release/juce_audio_basics.cpp.win32.o] Error 1 make[1]: Leaving directory '/tmp/pamac-build-harv/carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_audio_basics' make: *** [Makefile:131: /tmp/pamac-build-harv/carla-bridges-win32-git/src/carla-bridges-win32-git/build/modules/Release/juce_audio_basics.win32.a] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

SpotlightKid commented on 2017-07-10 16:08 (UTC)

Anyone else getting this error? make[1]: Leaving directory '/home/chris/src/arch/packages/carla-bridges-win32-git/src/carla-bridges-win32-git/source/jackbridge' make[1]: Entering directory '/home/chris/src/arch/packages/carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_data_structures' Compiling juce_data_structures.cpp (32bit) In file included from ../juce_core/juce_core.h:236:0, from juce_audio_basics.h:60, from juce_audio_basics.cpp:42: ../juce_core/maths/juce_NormalisableRange.h: In member function 'ValueType juce::NormalisableRange<ValueType>::convertFrom0to1(ValueType) const': ../juce_core/maths/juce_NormalisableRange.h:132:13: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (skew != static_cast<ValueType> (1) && proportion > ValueType()) ^~ ../juce_core/maths/juce_NormalisableRange.h:135:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if' return start + (end - start) * proportion; ^~~~~~ In file included from ../juce_core/juce_core.h:236:0, from ../juce_events/juce_events.h:60, from juce_data_structures.h:53, from juce_data_structures.cpp:36: ../juce_core/maths/juce_NormalisableRange.h: In member function 'ValueType juce::NormalisableRange<ValueType>::convertFrom0to1(ValueType) const': ../juce_core/maths/juce_NormalisableRange.h:132:13: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (skew != static_cast<ValueType> (1) && proportion > ValueType()) ^~ ../juce_core/maths/juce_NormalisableRange.h:135:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if' return start + (end - start) * proportion; ^~~~~~ Creating juce_data_structures.win32.a make[1]: Leaving directory '/home/chris/src/arch/packages/carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_data_structures' make[1]: Entering directory '/home/chris/src/arch/packages/carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_events' Compiling juce_events.cpp (32bit) In file included from juce_audio_basics.cpp:93:0: buffers/juce_FloatVectorOperations.cpp: In static member function 'static void juce::FloatVectorOperations::enableFlushToZeroMode(bool)': buffers/juce_FloatVectorOperations.cpp:1010:1: internal compiler error: in ix86_compute_frame_layout, at config/i386/i386.c:12444 } ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. make[1]: *** [Makefile:87: ../../../build/juce_audio_basics/Release/juce_audio_basics.cpp.win32.o] Error 1 make[1]: Leaving directory '/home/chris/src/arch/packages/carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_audio_basics' make: *** [Makefile:131: /home/chris/src/arch/packages/carla-bridges-win32-git/src/carla-bridges-win32-git/build/modules/Release/juce_audio_basics.win32.a] Error 2 make: *** Waiting for unfinished jobs....

Joermungand commented on 2016-12-11 12:16 (UTC)

@SpotlightKid: I am aware of the AUR package, thank you, but it does not install all the files that the bridges require in order to build – plus one file needs patching. So I’m stuck with this for the time being. @GraysonPeddie: It was my fault as I failed to notice Steinberg had updated the SDK on their website. Thanks for pointing it out. I have updated both packages and they should build now (they have on my system).

SpotlightKid commented on 2016-12-10 21:26 (UTC) (edited on 2016-12-10 21:27 (UTC) by SpotlightKid)

There's now also an AUR package, which installs the Steinberg VST SDK. You can have a look, for example, at my dexed-git package how it can be used: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dexed-vst-git

GraysonPeddie commented on 2016-12-10 21:18 (UTC)

The VST SDK download leads to a 404 not found. This will also occur in win64 version as well.

ask commented on 2016-03-14 20:22 (UTC)

Thanks for the cue, after I installed gcc-multilib it worked.

Joermungand commented on 2016-03-10 08:13 (UTC)

I cannot reproduce the error. I’ve yet to make some tests, but I’m wondering whether this might be because I have the multilib build toolchain installed.

ask commented on 2016-03-09 21:26 (UTC)

Building this packages fails for me with the this mesasage: make[1]: Entering directory '/tmp/carla-bridges-win32-git/src/carla-bridges-win32-git/source/jackbridge' Linking jackbridge-wine32.dll.so /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib/crti.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/crtbeginS.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/crtendS.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../lib/crtn.o' is incompatible with i386 output collect2: error: ld returned 1 exit status winegcc: g++ failed Makefile:126: recipe for target '../../build/modules/Release/jackbridge-wine32.dll.so' failed Is there a dependency missing?

Joermungand commented on 2015-12-12 17:10 (UTC)

I think I’ll stick with the package() version for now – at least until I get slapped for it :).

SpotlightKid commented on 2015-12-12 16:23 (UTC)

If you use an install file, add '|| return 0' to the line starting with 'rmdir', otherwise de-installing will issue a warning.

Joermungand commented on 2015-12-12 15:58 (UTC)

I’m not shy of using an .install file either. Don’t know which one is more appropriate.

SpotlightKid commented on 2015-12-12 15:54 (UTC)

You could also use an .install file: post_install() { make_symlinks lv2 make_symlinks vst } post_remove() { remove_symlinks lv2 remove_symlinks vst } remove_symlinks() { for name in carla-bridge-win64.exe carla-discovery-win64.exe \ jackbridge-wine64.dll; do rm -f "/usr/lib/$1/carla.$1/${name}" done rmdir "/usr/lib/$1/carla.$1" 2> /dev/null } make_symlinks() { mkdir -p "/usr/lib/$1/carla.$1" for name in carla-bridge-win64.exe carla-discovery-win64.exe \ jackbridge-wine64.dll; do ln -sf "/usr/lib/carla/${name}" "/usr/lib/$1/carla.$1/${name}" done } But your solution is probably simpler and more robust.

Joermungand commented on 2015-12-12 15:49 (UTC)

It works like this: cd "$srcdir/$pkgname" mkdir -p "$pkgdir/usr/lib/carla" cp bin/*.exe "$pkgdir/usr/lib/carla/" cp bin/*.dll "$pkgdir/usr/lib/carla/" mkdir -p "$pkgdir/usr/lib/lv2/carla.lv2" mkdir -p "$pkgdir/usr/lib/vst/carla.vst" cd "$pkgdir/usr/lib/carla" ln -sr *.exe ../lv2/carla.lv2/ ln -sr *.exe ../vst/carla.vst/ ln -sr *.dll ../lv2/carla.lv2/ ln -sr *.dll ../vst/carla.vst/ Deleted exe, dll files in /usr/lib/carla reinstalled package. Links are there.

falkTX commented on 2015-12-12 15:21 (UTC)

Try deleting /usr/lib/carla/*.exe (simulating first install) and see if it still works.

Joermungand commented on 2015-12-12 15:19 (UTC)

It works with relative links.

falkTX commented on 2015-12-12 15:08 (UTC)

yes, but since we'd creating a symlink to a location that might not exist ($pkgdir might set) it makes things tricky. if you do $ ln -s $pkgdir/usr/lib/carla/*.exe $pkgdir/usr/lib/lv2/carla.lv2/ then the link will fail because $pkgdir is a random path used for building. if you do: $ ln -s /usr/lib/carla/*.exe $pkgdir/usr/lib/lv2/carla.lv2/ it will fail on the first time you try to install this package, because there are no *.exe files in /usr/lib/carla yet. if you know of something simple that works, let us know. afaik this requires a 'for' loop.. copying the file is just much simpler.

SpotlightKid commented on 2015-12-12 15:02 (UTC)

Wouldn't it be more efficient to use symlinks instead of copies?

Joermungand commented on 2015-12-12 14:54 (UTC)

You’re welcome. Already updated.

falkTX commented on 2015-12-12 14:50 (UTC)

Cool, thanks very much. Please don't forget to update the win64 package as well.

Joermungand commented on 2015-12-12 14:41 (UTC)

Done.

falkTX commented on 2015-12-12 14:16 (UTC)

small request, please copy the *.exe and *.dll files to the lv2 and vst plugin dirs. ie, add this to the package function: mkdir -p "$pkgdir/usr/lib/lv2/carla.lv2" cp bin/*.exe "$pkgdir/usr/lib/lv2/carla.lv2/" cp bin/*.dll "$pkgdir/usr/lib/lv2/carla.lv2/" mkdir -p "$pkgdir/usr/lib/vst/carla.vst" cp bin/*.exe "$pkgdir/usr/lib/vst/carla.vst/" cp bin/*.dll "$pkgdir/usr/lib/vst/carla.vst/"

Joermungand commented on 2015-12-01 11:40 (UTC)

Done.

falkTX commented on 2015-12-01 11:25 (UTC)

some people have been reporting issues to me, regarding missing liblo. please replace the line: make win32 with this: make win32 HAVE_LIBLO=false thanks

Joermungand commented on 2015-11-23 08:22 (UTC)

Package fixed thanks to falkTX. Builds fine now.

SpotlightKid commented on 2015-11-22 17:39 (UTC)

Yeah, seems to fixed, but I'm getting a new compilation error. Whcih mingw-w64 package am I missing now? In file included from ../backend/CarlaStandalone.cpp:1906:0: ../utils/CarlaPipeUtils.cpp:42:23: schwerwiegender Fehler: sys/wait.h: Datei oder Verzeichnis nicht gefunden Kompilierung beendet. Makefile:349: die Regel für Ziel „../../build/bridges-plugin/Release/CarlaStandalone.cpp.win32.o“ scheiterte make[1]: *** [../../build/bridges-plugin/Release/CarlaStandalone.cpp.win32.o] Fehler 1 make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet... make[1]: Verzeichnis „/home/chris/tmp/yaourt-tmp-chris/aur-carla-bridges-win32-git/src/carla-bridges-win32-git/source/bridges-plugin“ wird verlassen Makefile:217: die Regel für Ziel „win32“ scheiterte make: *** [win32] Fehler 2

falkTX commented on 2015-11-22 16:42 (UTC)

I believe the build issue is now fixed. I'd appreciate if someone could confirm, thanks.

Joermungand commented on 2015-11-19 12:03 (UTC)

Yeah, it seems JUCE is having trouble compiling against mingw again. Please use the 2.0 beta 4 binaries (PKGBUILD available at https://aur.archlinux.org/packages/carla-bridges-win) while things get fixed.

SpotlightKid commented on 2015-11-19 11:51 (UTC)

Compilation (version 2631.03f5746-1) fails for me. Not sure if the package or the Carla repo is at fault. make[1]: Entering directory '/home/chris/tmp/yaourt-tmp-chris/aur-carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/juce_data_structures' Compiling juce_data_structures.cpp (32bit) In file included from juce_core.cpp:132:0: files/juce_File.cpp: In member function 'bool juce::File::createSymbolicLink(const juce::File&, bool) const': files/juce_File.cpp:917:48: error: 'SYMBOLIC_LINK_FLAG_DIRECTORY' was not declared in this scope isDirectory() ? SYMBOLIC_LINK_FLAG_DIRECTORY : 0) != FALSE; ^ files/juce_File.cpp:917:80: error: 'CreateSymbolicLink' was not declared in this scope isDirectory() ? SYMBOLIC_LINK_FLAG_DIRECTORY : 0) != FALSE; ^ In file included from juce_core.cpp:210:0: native/juce_win32_Files.cpp: In member function 'juce::File juce::File::getLinkedTarget() const': native/juce_win32_Files.cpp:653:34: error: '::GetFinalPathNameByHandleW' has not been declared DWORD requiredSize = ::GetFinalPathNameByHandleW (h, nullptr, 0, FILE_NAME_NORMALIZED); ^ native/juce_win32_Files.cpp:660:32: error: '::GetFinalPathNameByHandleW' has not been declared requiredSize = ::GetFinalPathNameByHandleW (h, buffer, requiredSize, FILE_NAME_NORMALIZED); ^ Makefile:85: recipe for target '../../../build/juce_core/Release/juce_core.cpp.win32.o' failed make[1]: *** [../../../build/juce_core/Release/juce_core.cpp.win32.o] Error 1

falkTX commented on 2015-10-11 20:54 (UTC)

the issue with 32bit bridges on 64bit systems has been fixed in carla-standalone. testing is welcome. don't forget to rebuild both carla and the bridges. btw, 32bit jack clients still only cause xruns, but that's a bug for another package.

superprick commented on 2015-05-10 01:03 (UTC)

A little more info. All 32bit windows apps trying to access jack do not work and send xruns climbing hundreds per second. Recently tried reaper 32 bit with wineasio. as soon as a track is opened it happens. However the 64 bit version of reaper is fine. so its either a wine problem or a jack problem. Using jackd2 on both arch and ubuntu 15 produces same results

Joermungand commented on 2015-04-25 17:17 (UTC)

Thanx, falkTX, got it. I’m still investigating the 32-bit win VST issue. Will make a resolution once that reaches any conclusive result.

falkTX commented on 2015-04-25 17:06 (UTC)

you need to use "make HAVE_LIBLO=false" so it properly skips the liblo check.

Joermungand commented on 2015-04-25 15:04 (UTC)

SpotlightKid, nothing’s wrong with the compilation flags. You need to install mingw-w64-liblo, available here: https://aur.archlinux.org/packages/mingw-w64-liblo . I removed it as a dependency, since it was no longer needed – yet apparently it is required as a build-dep. I’m not updating the PKGBUILD, yet, as I’m first trying to find out what’s wrong with the 32 bridges (not currently working).

superprick commented on 2015-04-19 11:19 (UTC)

yes both locally built and source forge binaries. Joermungand reported the same issue. I will go one step more to report that it does the same in Vanilla Ubuntu 15.04 beta 2 and ubuntu studio 15.04 beta 2. On the same machine it works fine on ubuntu 14.04. This would lead me to believe that new libraries or packages upstream are are causing the problem. something to look into as you will probably recieve more reports as the new ubuntu is releaseed.

falkTX commented on 2015-04-19 10:33 (UTC)

You mean you used the binaries linked from the kxstudio webpage and it still gives the same error? Because if it that's the case then this has nothing to do with my side. The 2.0-beta4 binaries were known to work at some point and have not changed.

superprick commented on 2015-04-19 03:59 (UTC)

Faltx have you been able to reproduce the issue that Joermengand and i have experienced. I downgraded my wine all the way back to 1.6.... same issue. both SF binaries and My own Build.

SpotlightKid commented on 2015-04-18 15:51 (UTC)

I get the following error while compiling: Compiling CarlaEngineOscSend.cpp (win32 bridge) In file included from ../backend/engine/CarlaEngineOsc.hpp:26:0, from ../backend/engine/CarlaEngineInternal.hpp:21, from ../backend/engine/CarlaEngine.cpp:26: ../utils/CarlaOscUtils.hpp:23:19: fatal error: lo/lo.h: No such file or directory #include <lo/lo.h> ^ compilation terminated. Makefile:339: recipe for target '../../build/bridges-plugin/Release/CarlaEngine.cpp.win32.o' failed /usr/include/lo/lo.h is present, so something must be wrong with the compilation flags.

Joermungand commented on 2015-04-16 11:26 (UTC)

I don’t know if this helps, but carla-discopvery issues warnings with virtually all plugins it detects. Most frequently, it’s ‘Plugin requested timeInfo but didn't ask if host could do "sendVstTimeInfo"’. Otherwise, it will be ‘Plugin requested idle more than once’. I won’t be around for the next couple of days. Will check back here as soon as I can.

Joermungand commented on 2015-04-16 09:26 (UTC)

My tests were performed with wine at 1.7.34.

falkTX commented on 2015-04-16 09:03 (UTC)

I rebuilt carla and all the bridges and they still work for me. I'm going to try updating wine.

Joermungand commented on 2015-04-16 08:01 (UTC)

Rebuilt Carla, rebuilt the bridge. Same behaviour here.

superprick commented on 2015-04-15 19:50 (UTC)

i see a git update for carla. building now

Joermungand commented on 2015-04-15 19:45 (UTC)

I get no complain about any missing library. In fact, wine does not complain at all on my side.

superprick commented on 2015-04-15 19:39 (UTC)

i am using the non realtime wine. i confirm the same behaviour. but my assertion failures are line 530 and 2657. This may be a clue also it complains that wine cannot find the ncurses library libncursesw.so.5. Maybe the win exe portions are not installing properly ?

Joermungand commented on 2015-04-15 18:19 (UTC)

*downloaded = downgraded (sorry)

Joermungand commented on 2015-04-15 18:15 (UTC)

I downloaded wine-rt all the way back to 1.7.34, recompiled win bridges, behaviour remains the same. Sometimes, I get a time-out error box in the GUI. Other times, the plugin loads, but I get Carla assertion failure: "! fTimedOut" in file CarlaPluginBridge.cpp, line 2646 in the terminal, followed by waitForClient(process) timeout here waitForClient(deactivate) timeout here If I try to activate the plugin I get the former of the last two lines again, then on the next attempt, I get both again.

Joermungand commented on 2015-04-15 16:29 (UTC)

Could be wine, indeed. Mine’s wine-rt v. 1.7.40 from the ArchAudio repos. I was supposed to leave this afternoon, but things got delayed so this gives me tonight to do some testing. I will downgrade wine and report.

falkTX commented on 2015-04-15 12:41 (UTC)

Could it be a wine error? It still works fine for me. Please try with some older wine version (mine is at 1.7.34)

superprick commented on 2015-04-15 12:38 (UTC)

This is truly strange. Was working fine before the latest update. Do we know if its a problem with the code or is this a build error on our machines

Joermungand commented on 2015-04-14 20:12 (UTC)

regsvr won’t work with the Carla bridges, it’s wineasio only. The bridges are executables, not dlls.

superprick commented on 2015-04-14 19:52 (UTC)

I have been reporting this for a few weeks. actually happened on ubuntu studio with kx repos also. i tried to regsvr the winebridge but it failed. dont know if that was needed though

Joermungand commented on 2015-04-14 16:11 (UTC)

Yeah, you’re right, I get the same. Hadn’t tested VSTs for a while. Same results with binaries from SourceForge. I don’t have any 64-bit VSTs, so I cannot tell. Except I cannot even enable the plugins, they all time out after a short while.

superprick commented on 2015-04-14 12:24 (UTC)

Sorry didnt mean wont build. As reported on LM forum. cannot get any 32bit vst to pass audio. only 64 bit work. I have both 32 and 64 bridges on a fresh arch install as of yesterday.

Joermungand commented on 2015-04-14 08:52 (UTC)

Strange. It builds here.

falkTX commented on 2015-04-14 07:33 (UTC)

what's the error?

Joermungand commented on 2015-03-14 20:22 (UTC)

I guess the initial comment I posted along with the PKGBUILD is no longer visible unless you view all comments. It reads: ‘This package depends on Steinberg’s VST3 SDK – without which, it will not build. A copy of it can be retrieved by signing in at http://www.steinberg.net/en/company/developers.html and has to be placed in the same directory as the PKGBUILD. The SDK version referred to in the PKGBUILD is vstsdk360_22_11_2013_build_100.zip, the latest at the time when the file was created. If you get a newer version, you will have to update the file name in the PKGBUILD, as well as its md5sum.’

moebius_rising commented on 2015-03-14 20:13 (UTC)

ERROR: vstsdk360_22_11_2013_build_100.zip was not found in the build directory and is not a URL.

Joermungand commented on 2015-01-14 19:26 (UTC)

Thanks, falkTX.

Joermungand commented on 2015-01-14 19:26 (UTC)

Yeah, sorry, I’d accidentally erased that. I’m so tired I don’t know what I’m doing any more. It builds fine now. I’ll update the PKGBUILD right away.

falkTX commented on 2015-01-14 19:09 (UTC)

You're missing the fthread.cpp patch, this line from PKGBUILD: sed -i 's/#if !PLATFORM_64/#if 0/' source/includes/vst/base/source/fthread.cpp So you have it already in the PKGBUILD, just forgot about it I guess... ;)

Joermungand commented on 2015-01-14 19:07 (UTC)

Hi, sorry about the delay. I figured out the vst2 bit earlier today while looking into egasimus’s report posted yesterday. I tested the build, but it failed again: http://pastebin.com/6gibEvcn

falkTX commented on 2015-01-14 16:08 (UTC)

btw, source/includes/vst is now source/includes/vst2 (note the extra "2"). this makes it easier to differentiate between vst2 and vst3. the PKGBUILD will need to be updated.

falkTX commented on 2015-01-14 16:05 (UTC)

Should be working now, please test and report back.

Joermungand commented on 2015-01-14 10:36 (UTC)

OK, thanks falkTX. I can do any testing that may be needed.

falkTX commented on 2015-01-14 10:30 (UTC)

Seems like the same issue as https://github.com/falkTX/Carla/issues/192 I need to update Juce to the latest version, then get an archlinux chroot to try out things until it works. This will take some time.

Joermungand commented on 2015-01-14 10:28 (UTC)

Here it goes: http://pastebin.com/2iwTC2wT

falkTX commented on 2015-01-14 10:14 (UTC)

please pastebin the full output of the build attempt. I'll see if I can get an archlinux chroot to test things...

Joermungand commented on 2015-01-14 10:13 (UTC)

@falkTX mingw issues persist on Arch. We’ll have to stick with the binaries.

Joermungand commented on 2015-01-14 09:19 (UTC)

Great! mingw-liblo has started to have issues compiling, anyway. I’m on to it.

falkTX commented on 2015-01-14 09:00 (UTC)

btw, mingw-liblo is no longer required. it can still be used to get osc-support for "carla-single" (as build-depend) but it's useless when using carla bridges.

falkTX commented on 2015-01-14 08:57 (UTC)

package should be updated. the code has changed quite a bit, and now plugin bridges are more reliable (testing welcome). it's still a work-in-progress, but it's getting better :) let me know if there are any issues.

Joermungand commented on 2015-01-13 20:50 (UTC)

I have temporarily put this package on hold for several reasons. For the one thing, the changes in mingw made it impossible to build the package at the time. At the same time, the Carla git code has evolved since, and I’m waiting for a stable green light from falkTX to try and build it again. Meanwhile, one should make do with the alternate package ‘carla-bridges-win’ (as suggested in my previous post), which installs ready-made binaries. I’m extremely busy at work right now, but I’m getting back on track as soon as I find the time and – and as soon as the compile environment becomes friendly again. Judging by your error, the mingw issues might have been solved. It remains to be seen when the bridges become usable again.

egasimus commented on 2015-01-13 20:38 (UTC)

The way it dies for me is, format_types/juce_VSTPluginFormat.cpp:49:44: fatal error: pluginterfaces/vst2.x/aeffectx.h: No such file or directory Even though I've got the VST SDK downloaded.

Joermungand commented on 2014-11-22 13:33 (UTC)

Since I couldn’t get the bridges to build with either the current version of mingw or the one from svn, I have created the ‘carla-bridges-win’ PKGBUILD, which provides the binaries available on SourceForge. That should do for now.

jarch-jarch commented on 2014-11-14 20:13 (UTC)

Great, thanks. :)

Joermungand commented on 2014-11-14 09:50 (UTC)

As falkTX has confirmed, newest commits in carla-git break the win bridges. We should stick to tag 1.9.5 for now. I.e. replace line 13 in the PKGBUIILD with source=("$pkgname"::'git://github.com/falkTX/Carla.git#tag=1.9.5' HOWEVER, mingw packages in Arch have been updated to newer versions since I wrote the PKGBUILD, which results in failure to build at some other point (at least on my system). I am currently investigating workarounds.

Joermungand commented on 2014-11-13 21:34 (UTC)

Right. I’m experiencing the same. It looks like carla-git has some code changes since I uploaded the PKGBUILD. I’ll get in touch with falkTX and report back as soon as I have an answer.

jarch-jarch commented on 2014-11-13 20:56 (UTC)

Getting this error on both 64 and 32 builds: Makefile:118: recipe for target 'JackBridgeExport.cpp.win32e.o' failed make[1]: *** [JackBridgeExport.cpp.win32e.o] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-j/aur-carla-bridges-win32-git/src/carla-bridges-win32-git/source/modules/jackbridge' Makefile:99: recipe for target 'source/modules/jackbridge.win32e.a' failed make: *** [source/modules/jackbridge.win32e.a] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build carla-bridges-win32-git. Saw down the comments (for Carla-Git, which I have successfully built) someone else had something similar but it was a problem with the Carla package or something? Anyone else getting it? Thanks.

Joermungand commented on 2014-10-27 19:42 (UTC)

This package depends on Steinberg’s VST3 SDK – without which, it will not build. A copy of it can be retrieved by signing in at http://www.steinberg.net/en/company/developers.html and has to be placed in the same directory as the PKGBUILD. The SDK version referred to in the PKGBUILD is vstsdk360_22_11_2013_build_100.zip, the latest at the time when the file was created. If you get a newer version, you will have to update the file name in the PKGBUILD, as well as its md5sum.