I am using the latest version of Hollyhock 64bit on windows. i have noticed a strange behavior that does not happen with my other DAW's.
I am using one controller (an ewi) to play a synth. The EWI is sending on one midi port into Hollyhock. It sends note on/off aftertouch and CC2 on channel 1. Everything is fine so far. However if i use a second midi input l and send CC messages even on a different channel it causes note glitches on the ewi channel. It was subtle and i didn't notice it at first. The problems i heard are like some random transposition and other glitchy things possibly note off/on getting messed up. I was trying to use an expression pedal sending out cc 1 on ch 16 to a different midi port to control some features in the synth like a mod wheel since the EWI doesn't have a modwheel.I tried a few different midi input devices such as Logidy UMI3 and softstep2. the problem persisted. I tried a different synth. same problem. The problem is not with the controllers. It seems that somewhere upon entering hollyhock the midi streams are getting tangled.
to test:
i made the simplest of workspaces to test this with.
one synth played by controller A (EWI)
play 3 notes notes quickly in a repeated pattern. or any repeated simple pattern so you can hear if there are glitches.
then in the global midi prefs add a second controller.
it doesn't even need to be added in the workspace anywhere. if you send cc1 on (any channel) separate from the controller you are playing the notes with to usine it will mess up the notes occasionally.
Its as if there are leaky midi pipes in the heart of Usine.
i hope i made this clear perhaps i will need to upload photos and audio demos if nobody can duplicate this strange behavior.
i hope this can be fixed. I really want to be able to use a foot pedal to send CC messages without affecting my note input.
PS in ableton this problem doesn't exist for me. i can select different input ports in the preferences and they do not affect each other.
seamus
midi bug
Hmm yea, I've had a couple of odd things happening with my external hardware since migrating from v5 to Hollyhock which I suspect may be MIDI related. Best chance for the Usine team to confirm this is if you can provide a reproducible example patch or workspace. Also might be most efficient to use the bug report section. http://www.sensomusic.com/wiki2/doku.ph ... bugsreport
it seems to only happen with the input of my ewi into my Babyface midi input port. trying to sort out the culprit with this problem is hard.!!!!
im not sure how to replicate this problem for the team to study since it involves midi coming into usine not something that is patch related.
since the ewi is sending out a rather dense stream then adding a dense cc stream of a mod wheel it could be just overloading.
i thought different ports and channels would insulate the midi streams from each other but they do appear to be able in certain situations to cause small glitches.. it is at this point impossible to play the ewi and use a expression pedal sending out cc. i will test another midi interface tomorrow.
Seamus
im not sure how to replicate this problem for the team to study since it involves midi coming into usine not something that is patch related.
since the ewi is sending out a rather dense stream then adding a dense cc stream of a mod wheel it could be just overloading.
i thought different ports and channels would insulate the midi streams from each other but they do appear to be able in certain situations to cause small glitches.. it is at this point impossible to play the ewi and use a expression pedal sending out cc. i will test another midi interface tomorrow.
Seamus
yes this is a good candidate for a bug report , i will try to investigate on my side,
try to test different combination on your side too if you can and if you have several controllers , i know that the ewi send a lot of Midi messages in the same time, have you tried to filter message..?
only note for the VSTi, only cc on another rack and so...
try to test different combination on your side too if you can and if you have several controllers , i know that the ewi send a lot of Midi messages in the same time, have you tried to filter message..?
only note for the VSTi, only cc on another rack and so...
Thanks I will test more. Yes the ewi sends pitch bend cc 2 aftertouch and note and cc5 sometimes. So it's a dense stream. I will try some more things and send a bug report! Still love hollyhock though!
-
fractalist
- Member
- Posts: 84
- Contact:
damned, I didn't see that bug report place.
the problem is more general, and yes I guess it happens when midi enters hollyhock.
I didn't report that problem here neither because it was already mentioned by someone having stuck notes issues, but there wasn't any reply from the team on this.
the other reason, to be honest, is that every time I run into these basic issues, I'm getting so upset that I feel I'm not in the right mood to communicate properly about it. plus I kept thinking the problem came from me. but it's definitely not.
I guess I've spent entire days on this, so these remarks could help :
when I use my MIDI controller, I have midi stuck notes (I guess most of "note on" are ok, issues seem to emerge with "notes off" : they aren't taken into account - and by the way, even the "all notes off" might not work properly in the case of my issues at least) .
the midi controller is a little ring called "Hot Hand USB" http://www.sourceaudio.net/products/hothand/
a simple software translates acceleration into midi, and I get the CC midi data in Usine. and it's a disaster (no troubles at all with ableton).
the midi CC from the hot hand are fine : I used them for weeks to process audio signals when I built my patches. but once it was good enough to start to play midi notes live... it became a mess, I can't even play 3 notes without having issues.
I've did so many tests and nothing works : midi filtering, using different racks and sending through a bus, using only different channels, or only one channel for everything, sending pitch bend instead of midi CC or whatever...
In fact, even if I don't even use the Hot Hand device as an input in a rack, this shit happens. it is sufficient enough to have the device "activated" in the midi setup panel, as an input. so the problem seems to be there (as far as I remember, if midi comes from a piano roll file, there is no such problem).
I thought I would overcome this problem later with some not so pleasant workarounds such as routing different softwares, in order to NOT get the data from the hot Hand software. so tonight I tried to route hot hand towards Max/msp towards Usine.... same shit. again, having "from max" activated in the midi setup panel is enough to mess things up, you don't even need to use it in the workspace.
Overall, hollyhock doesn't seem to be able to process both midi notes and real-time control changes at the same time, which sounds terrible if it is supposed to be dedicated to live music and real-time things.
Now, if anybody has any alternative solution for this, I take it.
I actually bought Usine for a gig, and spent all my free time these last 4 months trying to get something working. The gig was based on playing VSTi with MIDIfied guitar while interacting with (reasonably simple) motion capture. I worked on separated patches and since I integrated them in one workspace to do my thing, well, I can't play anymore.
too bad because I didn't had the time to compose anything while I spent all this time trying to figure out what was going on, and now I only have 3 days left to compose+rehearse, but it doesn't even work at all so... I take any alternative solution. for instance, I thought about transforming midi into osc outside of usine and using the incoming osc messages... but I don't know how to do it, plus I feel it might be yet another time consuming workaround trial that will probably fail in the end.
I'm devastated with the situation but at least I hope that my descriptions will be of some help to you (at least like not testing what I already tested and seeing the issue of the OP as a more general problem).
the problem is more general, and yes I guess it happens when midi enters hollyhock.
I didn't report that problem here neither because it was already mentioned by someone having stuck notes issues, but there wasn't any reply from the team on this.
the other reason, to be honest, is that every time I run into these basic issues, I'm getting so upset that I feel I'm not in the right mood to communicate properly about it. plus I kept thinking the problem came from me. but it's definitely not.
I guess I've spent entire days on this, so these remarks could help :
when I use my MIDI controller, I have midi stuck notes (I guess most of "note on" are ok, issues seem to emerge with "notes off" : they aren't taken into account - and by the way, even the "all notes off" might not work properly in the case of my issues at least) .
the midi controller is a little ring called "Hot Hand USB" http://www.sourceaudio.net/products/hothand/
a simple software translates acceleration into midi, and I get the CC midi data in Usine. and it's a disaster (no troubles at all with ableton).
the midi CC from the hot hand are fine : I used them for weeks to process audio signals when I built my patches. but once it was good enough to start to play midi notes live... it became a mess, I can't even play 3 notes without having issues.
I've did so many tests and nothing works : midi filtering, using different racks and sending through a bus, using only different channels, or only one channel for everything, sending pitch bend instead of midi CC or whatever...
In fact, even if I don't even use the Hot Hand device as an input in a rack, this shit happens. it is sufficient enough to have the device "activated" in the midi setup panel, as an input. so the problem seems to be there (as far as I remember, if midi comes from a piano roll file, there is no such problem).
I thought I would overcome this problem later with some not so pleasant workarounds such as routing different softwares, in order to NOT get the data from the hot Hand software. so tonight I tried to route hot hand towards Max/msp towards Usine.... same shit. again, having "from max" activated in the midi setup panel is enough to mess things up, you don't even need to use it in the workspace.
Overall, hollyhock doesn't seem to be able to process both midi notes and real-time control changes at the same time, which sounds terrible if it is supposed to be dedicated to live music and real-time things.
Now, if anybody has any alternative solution for this, I take it.
I actually bought Usine for a gig, and spent all my free time these last 4 months trying to get something working. The gig was based on playing VSTi with MIDIfied guitar while interacting with (reasonably simple) motion capture. I worked on separated patches and since I integrated them in one workspace to do my thing, well, I can't play anymore.
too bad because I didn't had the time to compose anything while I spent all this time trying to figure out what was going on, and now I only have 3 days left to compose+rehearse, but it doesn't even work at all so... I take any alternative solution. for instance, I thought about transforming midi into osc outside of usine and using the incoming osc messages... but I don't know how to do it, plus I feel it might be yet another time consuming workaround trial that will probably fail in the end.
I'm devastated with the situation but at least I hope that my descriptions will be of some help to you (at least like not testing what I already tested and seeing the issue of the OP as a more general problem).
I tested some more today. I thought by easing up on my midi stream with the ewi it may solve the problem. I turned off aftertouch and midi cc2 so the only data going in from the ewi controller was note on /off and pitch bend (can't turn that off on the ewi i don't think) i played 3 notes over and over again while using a foot pedal on a separate device to send midi cc messages. Without the cc foot pedal device even being fed into a rack the problem is still there. if the foot pedal is an active device in the global setup problems arise. Notes are getting messed up. Its like leaky midi pipes. I would say this is a bug and a pretty serious one.
We should be able to play notes and send cc messages at the same time with out the note information getting messed up. It seems to glitch about 5-10% just enough to drive you mad. Seems like a problem at the core of the software and may or may not be such an easy fix.
We should be able to play notes and send cc messages at the same time with out the note information getting messed up. It seems to glitch about 5-10% just enough to drive you mad. Seems like a problem at the core of the software and may or may not be such an easy fix.
@fractalist
yes, it's a pity you don't send a bug report before, specially if you have problems since 4 months !
I'm a bit surprised, cause no other users report such a problem until today , but I'll try to investigate on my side of course. But actually i can receive note and controller messages in the same time without problems.
have you try with older versions of Usine..? same problem? or is it only with 008m ?
yes, it's a pity you don't send a bug report before, specially if you have problems since 4 months !
I'm a bit surprised, cause no other users report such a problem until today , but I'll try to investigate on my side of course. But actually i can receive note and controller messages in the same time without problems.
have you try with older versions of Usine..? same problem? or is it only with 008m ?
btw, have you try to reduce you block size when testing ...?
Yeah, if I do the three note thing (on my midi keyboard) and see-saw on my FCB expression pedal (CC 11), notes start dropping. I've never noticed problems with stuff like this.... even controlling parameters via MIDI with the Leap Motion controller (with Geco) seemed fine, but I may need to re-evaluate.
@fractalist... do you know of Copperlan? Easy enough MIDI to OSC conversion. I've not tried the actual Copperlan protocol however but it looks promising.
Edit: Sorry my bad, it's the Geco app (Leap Motion App) doing the midi to OSC conversion. I'll try and help solve your problem though...
@fractalist... do you know of Copperlan? Easy enough MIDI to OSC conversion. I've not tried the actual Copperlan protocol however but it looks promising.
Edit: Sorry my bad, it's the Geco app (Leap Motion App) doing the midi to OSC conversion. I'll try and help solve your problem though...
@Nay - Where is the 'time stamp' data from the time parameter output on the MIDI modules? I can't shift it from 0 ms. Is it sysex related?
I was just thinking along the lines of patching together some kind of chronological sorting.
I was just thinking along the lines of patching together some kind of chronological sorting.
-
fractalist
- Member
- Posts: 84
- Contact:
a pity i know, being angry @ myself on this, but as I said I thought I was responsible for the error (especially cause I haven't seen much problem with this regarding to that issue, with a few exception : one thread with stuck midi notes, and this one, and latest observations of seamus also point out that it is enough to have the device activated in the setup panel for the problem to arise), and sometimes continued to elaborate my patch while thinking I would find the error later.
at some point I thought it was a weird failing interaction between midi notes and my particular midi software that inputs the data.
so I work for some time waiting for a free moment to trick it with max... was quite sure the trick would work
yes I also tried to reduce the block size (well, actually it is was already at the beginning). should I try lower values than 64 ?
Yes, same problem with older version of Usine, at least with 1.03 (but I'll try this again).
a few more tests to help :
actually, it is not a CC problem at all : I used max to transform the CC into note message : same problem.
I thereby think Seamus is pointing out the problem very well "The problem is not with the controllers. It seems that somewhere upon entering hollyhock the midi streams are getting tangled"
To further verify it, I smoothed the data really much in the external midi software (up to a point that it is not usable for me, but that was for the sake of testing) : if I send only one stream of data (in reality I need X Y Z acceleration, from 2 two rings : one control effects, the other has the purpose to implement a tempo follower from my right hand movements), and set up the maximum smoothing possible, it "almost" work well.
definitely sounds to me like a problem in the incoming stream of data, same guess as Seamus.
I think I tested everything I could on my side but if you have ideas, just tell me !
at some point I thought it was a weird failing interaction between midi notes and my particular midi software that inputs the data.
so I work for some time waiting for a free moment to trick it with max... was quite sure the trick would work
yes I also tried to reduce the block size (well, actually it is was already at the beginning). should I try lower values than 64 ?
Yes, same problem with older version of Usine, at least with 1.03 (but I'll try this again).
a few more tests to help :
actually, it is not a CC problem at all : I used max to transform the CC into note message : same problem.
I thereby think Seamus is pointing out the problem very well "The problem is not with the controllers. It seems that somewhere upon entering hollyhock the midi streams are getting tangled"
To further verify it, I smoothed the data really much in the external midi software (up to a point that it is not usable for me, but that was for the sake of testing) : if I send only one stream of data (in reality I need X Y Z acceleration, from 2 two rings : one control effects, the other has the purpose to implement a tempo follower from my right hand movements), and set up the maximum smoothing possible, it "almost" work well.
definitely sounds to me like a problem in the incoming stream of data, same guess as Seamus.
I think I tested everything I could on my side but if you have ideas, just tell me !
-
fractalist
- Member
- Posts: 84
- Contact:
thanx a lot Blaakk !
I guess your edit unfortunately means Geco can't get midi from something else than the leap right ?
so the problem is with the FCB too.. thanx for pointing it out, I was about to test that too !
I guess your edit unfortunately means Geco can't get midi from something else than the leap right ?
so the problem is with the FCB too.. thanx for pointing it out, I was about to test that too !
Hehe, sorry.... just edited my last post.
I think the sorting would introduce a 'bloc' delay, but it shouldn't be too tough to do. Well, it seems easy enough in my head. I'm seeing both of the expected notes on and off in the trace when MIDI data starts messing, so we should be able to access the correct data from the UI.
I think.
I think the sorting would introduce a 'bloc' delay, but it shouldn't be too tough to do. Well, it seems easy enough in my head. I'm seeing both of the expected notes on and off in the trace when MIDI data starts messing, so we should be able to access the correct data from the UI.
I think.
I'll check... yes. Just Leap frame data to midi or osc (or Copperlan).
-
fractalist
- Member
- Posts: 84
- Contact:
thank you very much !
only one bloc delay would not be a problem for one of my controller (global body movements to mangle the sound while I play it).
It would be a problem for the other one (interpreting tight, discrete rhythmic impacts from the derivative of the data, cause there is almost already too much latency or not enough frequency resolution) but he, one thing at a time, I could "live" with it at the moment.
only one bloc delay would not be a problem for one of my controller (global body movements to mangle the sound while I play it).
It would be a problem for the other one (interpreting tight, discrete rhythmic impacts from the derivative of the data, cause there is almost already too much latency or not enough frequency resolution) but he, one thing at a time, I could "live" with it at the moment.
-
fractalist
- Member
- Posts: 84
- Contact:
Oh, just saw your edition but thanks for having check it out !
but thanks for having check it out !Since other folks are noticing the problem i suppose I will file an official bug report. I am sure it will get resolved eventually. Senso and the team are brilliant. I will keep my fingers crossed.
No problemios. I think I have a little workaround involving a data bus. Works fine with the FCB CC11 and notes from 88es keyboard from before. Basically it's midi-to-osc within Usine.
The uploader isn't working for me, so I'll describe briefly what I've done and then host image. It's pretty simple.
This assumes OSC is enabled in Usine.
My MIDI notes are going into my UCX MIDI IN 1 device. This midi device is left untouched.
My CC data goes through the UCX MIDI IN 2 device. Within the device I deleted the 'midi-to-usine' module. Then I routed code2 instead to an 'OSC Send' module. Left type as OSC float. An 'OSC Receive' module next to it receives the message and passes it to a send bus (which is dropped before the parameter to be controlled in the relevant rack (which only has UCX 1 midi as a rack input)
I haven't yet tested loading/saving or anything (just I remember a thread regarding things a problem when there's no 'midi-to-usine' module in a device.
The uploader isn't working for me, so I'll describe briefly what I've done and then host image. It's pretty simple.
This assumes OSC is enabled in Usine.
My MIDI notes are going into my UCX MIDI IN 1 device. This midi device is left untouched.
My CC data goes through the UCX MIDI IN 2 device. Within the device I deleted the 'midi-to-usine' module. Then I routed code2 instead to an 'OSC Send' module. Left type as OSC float. An 'OSC Receive' module next to it receives the message and passes it to a send bus (which is dropped before the parameter to be controlled in the relevant rack (which only has UCX 1 midi as a rack input)
I haven't yet tested loading/saving or anything (just I remember a thread regarding things a problem when there's no 'midi-to-usine' module in a device.
To me it should be unnecssary to deal with complicated workarounds to solve this problem. Usine should provide solid midi streams. If we want more people to use this software bugs like this should be solved.
Agreed. But...... it's still damn stable compared to anything I've used in the past, when put under similar circumstances. And it's still very nice and fruity looking. And for me, it's due to some things not exactly working how they should (and not been too difficult to work around) which has spurred me to go from been a nooooob with coding and strictly audio, 'listen-to-a-kick-drum's-frequency-content-for-FAR-too long' type of guy to someone who's now on there way to controlling audio-reactive 3D raymarched visuals in real time with multiple input devices, as well as by the frequency content of the music which I'm simultaneously creating on-the-fly. Once I learn to correctly access and use the frame data of various peripherals (in whatever language) I'm pretty much there in terms of having a show I can be extremely content with. Totally thanks to Sensomusic's software.
But I've had a lot more time than most recently. Without that fact then maybe these things wouldn't be looked upon with as much positivity. More devs seems like an absolute necessity.
But I've had a lot more time than most recently. Without that fact then maybe these things wouldn't be looked upon with as much positivity. More devs seems like an absolute necessity.
Usine can do a lot of different things for different people. So yes its great software I'm not going to stop using it but to have a second controller mess up the first is a relatively serious problem . I'm trying to play quick synth lines with a foot controller controlling some cc# 'ed parameters in the synth and my notes are messed up. Conclusion : cannot use a second controller while playing notes.
-
fractalist
- Member
- Posts: 84
- Contact:
also agree that the bug should be fixed but..... Blaakk.... how could I be thankful enough ????
It feels like "oh my god, I can walk again !"
my remaining problem is that I input several information (X+Y+Z * 2) at the same time. because all the dimensions aren't necessarily changing at the same time, in each bloc I can have various amount of data (between 1 and 6 depending on the moment), and I'm not sure how to sort that yet. doesn't the "unpack" option put information in a queue/line such that I might get a lot of latency when it needs 6 blocks instead of one to output information ?
second issue : i did as you said but OSC-receive didn't received anything... I didn't try to understand as that's not a problem because actually, if I use the data bus in the end, there is no need of the osc thing : I can just send code1 and code2 directly from the midi device, and it works !!!
on top of the working workaround, this narrows the focus of the issue towards the "midi to usine" module I guess.
It feels like "oh my god, I can walk again !"
my remaining problem is that I input several information (X+Y+Z * 2) at the same time. because all the dimensions aren't necessarily changing at the same time, in each bloc I can have various amount of data (between 1 and 6 depending on the moment), and I'm not sure how to sort that yet. doesn't the "unpack" option put information in a queue/line such that I might get a lot of latency when it needs 6 blocks instead of one to output information ?
second issue : i did as you said but OSC-receive didn't received anything... I didn't try to understand as that's not a problem because actually, if I use the data bus in the end, there is no need of the osc thing : I can just send code1 and code2 directly from the midi device, and it works !!!
on top of the working workaround, this narrows the focus of the issue towards the "midi to usine" module I guess.
It's nice to see a so called bug report be full of enthusiasm.
I will work on some other ideas in the meantime it's not the end if the world I can't wiggle my toes while at the same time wiggle my fingers.
There are ao many things possible it boggles the mind.
I wish all the folks in this community success.
Hollyhock is a badass piece of software. Unique and inspiring for sure!
I will work on some other ideas in the meantime it's not the end if the world I can't wiggle my toes while at the same time wiggle my fingers.
There are ao many things possible it boggles the mind.
I wish all the folks in this community success.
Hollyhock is a badass piece of software. Unique and inspiring for sure!
-
fractalist
- Member
- Posts: 84
- Contact:
why do you want to work on other ideas in the meantime ? it's even simpler for you than for me :
* in the "device in", connect a databus to "code2 of midi input" instead of the "midi to usine"
* instead of the "midi input" in your rack, use the databus.
5 seconds
* in the "device in", connect a databus to "code2 of midi input" instead of the "midi to usine"
* instead of the "midi input" in your rack, use the databus.
5 seconds
Hi Seamus, I have not had a chance to reproduce my errors.... but I wanted to concur that I had noticed some MIDI input problems.
My setup basically was running a separate DAW like Sonar and sending MIDI Sync into Hollyhock. I will use Tobias Internal MIDI routing for the Sync, and the sync works well, however my other external MIDI inputs will seem to get stuck on after awhile like the input flow is being overloaded. I had done this same setup in the past and never recall the problem, however the latest I thought it odd that this problem had surfaced as it had always been rock-solid.
-S
My setup basically was running a separate DAW like Sonar and sending MIDI Sync into Hollyhock. I will use Tobias Internal MIDI routing for the Sync, and the sync works well, however my other external MIDI inputs will seem to get stuck on after awhile like the input flow is being overloaded. I had done this same setup in the past and never recall the problem, however the latest I thought it odd that this problem had surfaced as it had always been rock-solid.
-S
"Every act of creation is first an act of destruction." -Picasso
It's becoming apparent there are issues thanks for confirming Sephult.
seamus, I just reconfirmed my midi issue as well. Here are my details:
Sonar X3 x64 - Empty Project, Send MIDI Sync (Transmit MIDI Start/Continue/Stop Clock Only), Using Tobias Ericson LoopMIDI
HollyHock 1.1008m x64 - Rack 1, Tobias Ericson LoopMIDI set to receive midi time clock.
I add Native Instruments Absynth 5 to track 2 using a MOTU MidiExpress port 1 - with a Yamaha M1 controller.
Results - MIDI response seems to be altered for note on at first, picking up a few notes here and there. Next it seems to be responding fine then all the sudden I end up with stuck notes. After panic the same response occurs.
I will try a few more configurations today and see if it just my configuration or what is going on. However I do not ever recall having this issue with the same setup.
-S
Sonar X3 x64 - Empty Project, Send MIDI Sync (Transmit MIDI Start/Continue/Stop Clock Only), Using Tobias Ericson LoopMIDI
HollyHock 1.1008m x64 - Rack 1, Tobias Ericson LoopMIDI set to receive midi time clock.
I add Native Instruments Absynth 5 to track 2 using a MOTU MidiExpress port 1 - with a Yamaha M1 controller.
Results - MIDI response seems to be altered for note on at first, picking up a few notes here and there. Next it seems to be responding fine then all the sudden I end up with stuck notes. After panic the same response occurs.
I will try a few more configurations today and see if it just my configuration or what is going on. However I do not ever recall having this issue with the same setup.
-S
"Every act of creation is first an act of destruction." -Picasso
seamus - Here is a new discovery on my specific setup. Wiring the clock seemed to be flooding a continuous system 0 message on the MIDI input port of my sync. It seems if I disconnect the From MIDI Device to "MIDI to Usine" I can break this flood however still maintain the clock from Sonar to Hollyhock. In my case it seems the incoming flood is what is causing my problem. I just realized to in the past I believe I used the actual Patch for MIDI sync more than the built in receive and send MIDI sync. I would love to see more control and ability to control to prevent flooding. I am not sure if your setup has as well, however there is obviously a point where MIDI becomes overwhelmed and possibly a lot sooner than we were used to in previous versions. I wonder if there is any prioritization of System exclusive messages or other messages over standard note messages internal, maybe at this point is where by sending multitudes of pitching commands and much greater intervals that then a note-off is dumped or missed. All just speculations, however I just wanted to help in regards. If you are having stuck notes, possibly look at the messages coming in and try to offload, minimize, or filter and redirect and you might be able to control and manage better until something can be improved internally in HollyHock.
-S
-S
"Every act of creation is first an act of destruction." -Picasso
Among this setup I am seeing also the following in which I am going to apply a bug report.
Using the MIDI sync, it will sync perfect for awhile then start to lag compared to Sonar.
At about 2 mins I can quite audibly hear fall behind with just two metronomes to a backbeat.
Using the MIDI sync, it will sync perfect for awhile then start to lag compared to Sonar.
At about 2 mins I can quite audibly hear fall behind with just two metronomes to a backbeat.
"Every act of creation is first an act of destruction." -Picasso
Yes, please, send a report for the clock question,
We follow this discussion and we made tests
about Midi CC + note corruption we'll of course, investigate around Usine device but you can also have some midi interface drivers which reach their limit quickly when sending a lot of informations
here an example
to test it , you need a sound card with Midi IN/OUT and a Din cable, send the rack 1 to the Midi input of your soundcard, the rack 2 receive the Midi Out of this same card. play the rack 1 and record on rack 2
note that this patch send a lot of informations , this don't correspond to real life , it 's only to stress the Midi flow. so be careful. For example it's a good idea to let the piano roll closed..But the result is that we don't have any corrupted notes( tested on several machine ( PC and Mac) , so this means that Usine can work with a big Midi flow
about the same question, some tips to test:
if you want record with the piano roll with heavy Midi flow, try to filter by events type and record them in different piano roll to test ( 1 for CC, 1 for notes...)
if you have several card or midi interface, test different configurations, avoid USB hubs, try different usb port and so..
We follow this discussion and we made tests
about Midi CC + note corruption we'll of course, investigate around Usine device but you can also have some midi interface drivers which reach their limit quickly when sending a lot of informations
here an example
to test it , you need a sound card with Midi IN/OUT and a Din cable, send the rack 1 to the Midi input of your soundcard, the rack 2 receive the Midi Out of this same card. play the rack 1 and record on rack 2
note that this patch send a lot of informations , this don't correspond to real life , it 's only to stress the Midi flow. so be careful. For example it's a good idea to let the piano roll closed..But the result is that we don't have any corrupted notes( tested on several machine ( PC and Mac) , so this means that Usine can work with a big Midi flow
about the same question, some tips to test:
if you want record with the piano roll with heavy Midi flow, try to filter by events type and record them in different piano roll to test ( 1 for CC, 1 for notes...)
if you have several card or midi interface, test different configurations, avoid USB hubs, try different usb port and so..
Thanks nay! I am doing some experiment with clock here. My specific overflow seems to be directed whenever I receive in a SPP, MTC, or Timing clock and send to USINE which seems to corrupt my other MIDI inputs. If I filter these out I have no problem, except my own personal synchronization issues I am battling at the moment between DAW.
Very interested on trying this example out and I will do so.
Very interested on trying this example out and I will do so.
"Every act of creation is first an act of destruction." -Picasso
i was using a usb hub for the second midi controller. I will test to see if this is an issue.
seamus I had some horrible experiences in the past using MIDI XPress XT in x64, which was a driver interaction problem. I would have things from odd note behavior, delays, connections lost, and even blue-screen. I have been using the same one and it is rock solid now since driver updates. Hopefully in your case it is just a driver issue or a simple fix, interested to know how it turns out.
"Every act of creation is first an act of destruction." -Picasso
i don't think this is my problem. The midi with my rme babyface works fine in other DAW's. Other people have noticed similar issues so it is something in the input stage of usine where the midi flow enters the program.
I tested without any devices using a usb hub and still the same issues with midi notes getting screwed up sometimes. I guess for now I do not send in cc's while I play notes.
Maybe you can filter the input to limit. At one point I had done a script that just passed odd values to limit the flow in the past.
Place the script just before the MIDI to USINE and maybe you can prevent the overflow.
Actually I just realized I put it in the add-ons. It's rough and I need to update. Basically I used two faders 0-127 integer Data IN to Output and a Knob set to Integer, 0-2. Mode 0 is bypass, 1 is Odds, 2 is evens. If you filter you can limit the CC flow into usine to only respond to your odds or evens...this might help.
Or Maybe you can isolate by splitting the Notes from the CC values on the input device that might help you identify exactly at which point you are having the overflow.
Place the script just before the MIDI to USINE and maybe you can prevent the overflow.
Actually I just realized I put it in the add-ons. It's rough and I need to update. Basically I used two faders 0-127 integer Data IN to Output and a Knob set to Integer, 0-2. Mode 0 is bypass, 1 is Odds, 2 is evens. If you filter you can limit the CC flow into usine to only respond to your odds or evens...this might help.
Or Maybe you can isolate by splitting the Notes from the CC values on the input device that might help you identify exactly at which point you are having the overflow.
"Every act of creation is first an act of destruction." -Picasso
Unfortunately this behavior occurs when a midi input is activated in midi setup preferences before I even send it to a rack.
Having the second midi device active in the preferences is enough to cause occasional notes drop out.
Having the second midi device active in the preferences is enough to cause occasional notes drop out.
Okay, well that is strange seamus.
So you are saying that having multiple MIDI drivers activated causes the issue?
I use a ton of MIDI devices simultaneously but do not see a problem this specific.
That case almost sounds like an install/config or Driver problem.
Have you tried de-activating all of your MIDI from setup then deleting all of your MIDI devices out of the "Devices" panel?
I would then re-scan MIDI and re-create them in the "Devices" section by activating them again. See if that behavior still exists.
I have recently noticed an issue with Arturia Beatstep, where every time I must delete the device from the panel, and re-activate.
If not I will get odd or no response. When I do all works as expected. I do not have to do this with any other devices.
Maybe there is a disconnect somewhere between the setup activated devices and the config/devices panel...a clue?
So you are saying that having multiple MIDI drivers activated causes the issue?
I use a ton of MIDI devices simultaneously but do not see a problem this specific.
That case almost sounds like an install/config or Driver problem.
Have you tried de-activating all of your MIDI from setup then deleting all of your MIDI devices out of the "Devices" panel?
I would then re-scan MIDI and re-create them in the "Devices" section by activating them again. See if that behavior still exists.
I have recently noticed an issue with Arturia Beatstep, where every time I must delete the device from the panel, and re-activate.
If not I will get odd or no response. When I do all works as expected. I do not have to do this with any other devices.
Maybe there is a disconnect somewhere between the setup activated devices and the config/devices panel...a clue?
"Every act of creation is first an act of destruction." -Picasso
Perhaps one way around the issue would be to combine the ewi midi stream and the logidy expression pedal/ midi switch into a midi bus so they come in at the same input although it will add more latency to my ewi midi. That may temporarily solve the problem.
Most keyboard players have the mod wheel built into their keyboard so the streams are connected.
As I said before I don't encounter this problem in ableton so it is a Usine specific issue. There are many things that I can only do in Usine so I'm not about to give up on the software and as you can see above there are others who are experiencing similar problems.
Did you try the test I outlined in an earlier post?
Most keyboard players have the mod wheel built into their keyboard so the streams are connected.
As I said before I don't encounter this problem in ableton so it is a Usine specific issue. There are many things that I can only do in Usine so I'm not about to give up on the software and as you can see above there are others who are experiencing similar problems.
Did you try the test I outlined in an earlier post?
So I have a Yamaha M1, I played a chord of three notes repeatedly via MIDI on the Motu Express XT USB. Using an Arturia Laboratory 49 via USB as well I did pitch and mod crazily, as well as tweaked many CC inputs.
So I had one rack with the M1 notes routed to Massive, and the laboratory is active. I did not really see any glitches.
Even with the laboratory in rack I did not have the glitches. In my case the only time I see glitches is if I am receiving timing clock from the LoopMIDI and it reaches the USINE interface in the device.
Is this close to the test you are explaining?
What version of HH you using are you purely x64 for all of your drivers as well?
I am using 1.1.008m x64
So I had one rack with the M1 notes routed to Massive, and the laboratory is active. I did not really see any glitches.
Even with the laboratory in rack I did not have the glitches. In my case the only time I see glitches is if I am receiving timing clock from the LoopMIDI and it reaches the USINE interface in the device.
Is this close to the test you are explaining?
What version of HH you using are you purely x64 for all of your drivers as well?
I am using 1.1.008m x64
"Every act of creation is first an act of destruction." -Picasso
Interesting that you don't have any problems Sephult. i wasn't playing a chord but single notes repeatedly alternating. It is interesting to say the least why some users don't get note glitches. the same thing in ableton is fine.
I know some other users have been able to reproduce the problems. I believe Blaak had the same results as me.
I am using the latest hollyhock 64 bit.
I know some other users have been able to reproduce the problems. I believe Blaak had the same results as me.
I am using the latest hollyhock 64 bit.
Have you tried my suggestion about deleting your devices from your device panel in HH and regenerating?
I have had oddities just overwriting config and HH directories in the past, also in the past have been curious about what happens when you update your hardware drivers after a config has already been generated.
Also are you sure all of your drivers are x64 as well? My earlier mention about the MOTU Midi Xpress was a driver problem that mostly happened in Sonar but would work other places quite well.
Definitely tricky business but you will get there.
I guess in my problem I was fortunate enough to get blue-screens ...lol. My first Win SDK debug experience but led me right to that driver every time. After bug reports, and no response. Magically Motu Drivers became solid for x64
I have had oddities just overwriting config and HH directories in the past, also in the past have been curious about what happens when you update your hardware drivers after a config has already been generated.
Also are you sure all of your drivers are x64 as well? My earlier mention about the MOTU Midi Xpress was a driver problem that mostly happened in Sonar but would work other places quite well.
Definitely tricky business but you will get there.
I guess in my problem I was fortunate enough to get blue-screens ...lol. My first Win SDK debug experience but led me right to that driver every time. After bug reports, and no response. Magically Motu Drivers became solid for x64
"Every act of creation is first an act of destruction." -Picasso
I will try that tip Sephult. Thanks. I will let you know.
i tried deleting the devices in midi device panel and reseting and that didn't change anything. The only way so far i have found to cure this problem is to have the 2 devices on the same midi bus. If i send the ewi and logidy foot pedal midi to MIDI-OX coming out of the same bus together I don't have the problem anymore. So this proves to me there are some leaky pipes with the midi signals going into Usine.
I suppose i will use my workaround for now but i would prefer to have the midi devices all separate and not bussed together.
I wonder If Senso is aware of this issue. I will file a bug report.
EDIT solution found!
in the midi devices i filter out the CC1 mod wheel info from the logidy controller and send that to a midi bus. this seems to have fixed the problem! YEAH! thanks everyone for your help!
I suppose i will use my workaround for now but i would prefer to have the midi devices all separate and not bussed together.
I wonder If Senso is aware of this issue. I will file a bug report.
EDIT solution found!
in the midi devices i filter out the CC1 mod wheel info from the logidy controller and send that to a midi bus. this seems to have fixed the problem! YEAH! thanks everyone for your help!
Awesome that is great to hear seamus!!!!
"Every act of creation is first an act of destruction." -Picasso
I had this same bug in a major way tonight...
I have multiple midi input devices, including a device I use as my master midi clock, and a couple of controllers. (Lots of PBs and CCs...)
I had lots of stuck notes... Many, many stuck notes... Reading this thread, I opened all the little midi device patchlets and disconnected Midi to Usine in each. Instead, I sent data straight to a midi bus. Similarly, in my patches, I disconnected ALL uses of Midi Input, and instead used my new midi buses.
I was going to do this anyway, since I think it is the only way to route data from different input midi devices/ports discreetly to different destinations. Send to Usine/Midi Input seems to merge data from all ports (which may explain things getting "tangled" as described above).
Anyway, hours of playing later and NOT ONE stuck note.
I'll see if this holds true over many days/ hours. So far, so good.
This is definitely a Usine issue. I have used the same gear/setup with other hosts & had no dropped notes. I abandoned the others for the programmability offered by Usine.
Hope this helps,
Shawn
I have multiple midi input devices, including a device I use as my master midi clock, and a couple of controllers. (Lots of PBs and CCs...)
I had lots of stuck notes... Many, many stuck notes... Reading this thread, I opened all the little midi device patchlets and disconnected Midi to Usine in each. Instead, I sent data straight to a midi bus. Similarly, in my patches, I disconnected ALL uses of Midi Input, and instead used my new midi buses.
I was going to do this anyway, since I think it is the only way to route data from different input midi devices/ports discreetly to different destinations. Send to Usine/Midi Input seems to merge data from all ports (which may explain things getting "tangled" as described above).
Anyway, hours of playing later and NOT ONE stuck note.
I'll see if this holds true over many days/ hours. So far, so good.
This is definitely a Usine issue. I have used the same gear/setup with other hosts & had no dropped notes. I abandoned the others for the programmability offered by Usine.
Hope this helps,
Shawn
Address the process rather than the outcome. Then, the outcome becomes more likely. - Fripp
You never could be. Muhahahahah.also agree that the bug should be fixed but..... Blaakk.... how could I be thankful enough ????
How did you get on with your gig then fractilist??? Nice one for t'other solution seamus/shawn!! I remember doing some pretty crazy routing in my first few days of HH.... forking a few midi streams, array-bending them, routing to various destinations (including midi LAN out, midi-busses) receiving at client, recording to piano roll, duplicating, sending back through a bus, etc. All of which behaved, yet all this type of routing began in the same device (following your original advice I believe).
Apologies for having 'jumped ship' here. Not long after my posts, I screwed up my SSD system drive and have since been in amongst getting to grips with GPT/UEFI installations (ie trying to fix it), and trying out Linux distros, studying driver development, Python, C/C++, JS/Coffeescript, version control and basically all that'll help me achieve controllable real-time audio-reactive shader pleasure (and stuff that probably wont). Khronos headers FTW! As well as all WebGL/GPUPU/Parallel Computing! And virtual networks/machines!
Hehe.... I'm getting there.
Sorry, a little diversion for yas here............ I was curious about something which I thought was a bug in the software (HH) on first opening my shiny archive a few months back... namely the demo workspace 'The Grid'. The audio was cutting out on line 3 'The Groove'. The reverb send was/is causing this in some way somehow. Not really a bug as such but... an inconvenience for any newbie sequentially working through these workspace tuts.
Thankfully related advice on the matter initiated a much needed system upgrade... but even with my new rig the same problem remains. Fresh install, current system/audio/video drivers, Win 8.1 (very impressed with this OS btw)..... loading 'The Grid' from an untouched extracted 1.1.008m (no chance of tainted config files as described be sephult) and then playing results in silence on switching to line 2.
Could any of you guys check this out from a fresh archive?
Hello,
This topic has pointed a possible issue in the midi chain of HH.
Normally it will be solved in the next release 1.1.009.
Thanks for all your feedbacks.
This topic has pointed a possible issue in the midi chain of HH.
Normally it will be solved in the next release 1.1.009.
Thanks for all your feedbacks.
Olivier Sens
www.brainmodular.com
www.brainmodular.com
Who is online
Users browsing this forum: No registered users and 121 guests