Gliss EQ is fn amazing, but... I'm having a problem:
The narrow-band feature is frequently crashing Logic (current version) the second I hit command+click and sweep with the mouse. I'm not able to sweep at all. I can only throw a peak at a certain frequency, then release and try for another. The problem begins when I start the sweep. If it doesn't crash, then I suffer another problem: the peak suddenly drops to a much lower gain down and to the left of the spectrum display. So it either crashes or acts nutty the moment the mouse is moved while the command key is held down.
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x92971ef6 __kill + 10
1 libSystem.B.dylib 0x92971ee8 kill$UNIX2003 + 32
2 libSystem.B.dylib 0x92a0462d raise + 26
3 libSystem.B.dylib 0x92a1a679 __abort + 124
4 libSystem.B.dylib 0x92a1a6f5 abort_report_np + 0
5 com.apple.logic.pro 0x00405649 std::ostream& TraceOutContainer<CEvs>(std::ostream&, CEvs, char const*, int) + 3974297
6 libSystem.B.dylib 0x929771fb _sigtramp + 43
7 ...o-plugins.audiounit.GlissEQ 0x5228026f vox::CControlSurfaceEvents::handlePointDrag(double, double, bool, bool, bool) + 399
8 ...o-plugins.audiounit.GlissEQ 0x52288dcd vox::CControlSurfaceEvents::onMouseMove(vox::CMap<vox::CString, vox::CAttribute>&) + 1901
9 ...o-plugins.audiounit.GlissEQ 0x51eee62d vox::CViewBaseCtlEvents::_onMouseMove(vox::CObject*, vox::CMap<vox::CString, vox::CAttribute>&) + 45
10 ...o-plugins.audiounit.GlissEQ 0x521148b6 vox::CObject::runEvent(vox::CString const&, vox::CMap<vox::CString, vox::CAttribute>&) + 118
11 ...o-plugins.audiounit.GlissEQ 0x52248ab9 vox::CWindow::onMouseMove(vox::CMap<vox::CString, vox::CAttribute>&) + 4745
12 ...o-plugins.audiounit.GlissEQ 0x51eec32a vox::CWindow::_onMouseMove(vox::CObject*, vox::CMap<vox::CString, vox::CAttribute>&) + 42
13 ...o-plugins.audiounit.GlissEQ 0x521148b6 vox::CObject::runEvent(vox::CString const&, vox::CMap<vox::CString, vox::CAttribute>&) + 118
14 ...o-plugins.audiounit.GlissEQ 0x522504f0 vox::UIWindow_MainWndProc_Perform(OpaqueEventHandlerCallRef*, OpaqueEventRef*, vox::CWindow*, long&) + 3712
15 ...o-plugins.audiounit.GlissEQ 0x52251903 vox::UIWindow_MainWndProc(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 67
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x92a1a609 ecx: 0xbfffd77c edx: 0x92971ef6
edi: 0x00ccb3bc esi: 0x4a96f080 ebp: 0xbfffd798 esp: 0xbfffd77c
ss: 0x0000001f efl: 0x00000282 eip: 0x92971ef6 cs: 0x00000007
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
Any progress on this? I'm going nuts without the ability to drag the mouse, and end up opening another EQ just to find the problem frequencies if I've run out of nodes to sacrifice for this task.
Also, what is the logic of including the modified curve during the use of this function? Seems a lot of folks (including me) would prefer that it drop the current EQ curve during the peak sweep.
I have discovered another bug regarding the bandpass issue.
When used in M-S stereo, adding a new band in the side window, makes it impossible move the ctrl. click bandpass in the mid window.
I have also had other problems here and there that the bandpass function hijacked another band and moved this as well. Tried this a few times, but can't tell you how/why this happened, but please take a thorough look into this otherwise wonderful feature!
This happens on the windows platform in both Samplitude and Wavelab
Otherwise GlissEQ is +++
Good Aleksey, I wondered what was going on so it's good to know that something is actually happening... do you know when it will be ready?
This topic was last updated 180 days ago, and thus it was archived. Replying is disabled for this topic.