Forum Replies Created
-
Posts
-
I’m stupid lol – I can just create something in knobman with 128 frames
Obviously didnt spend enough time thinking about it!
Hi Possemo
Thanks for replying.
It’s not a pulse bug. The values it outputs when below -32 are correct. The lowest (-48) being hex 10 which is what the manual says (value range is 16 to 112).
If it is a bug then it’s with ctrlr however I’m probably doing something wrong although the fact the tune control works makes me think I’m doing it right.
Is there a limit to how many values you can have in the slider contents box?
The for the replies guys – really appreciate it.
Goodweather – actually, I’d downloaded you pro2 patch to see how you used getByte before I posted but your use of getByte is different to what I want. Awesome looking panel though 🙂 makes me want a Pro2 lol (that and the sound of course!). And thanks for the examples – they will come in very useful as I hadn’t started to look at the decimal to hex converstion yet. Thanks!
Possemo – You’ve replied to a few of my posts and as ever – sage advice. As it happens, I’d just stumbled upon that very wiki page between my first and last post last night. Thats what allowed me to make some progress. I’ll check out the console – doesnt sound like it will be as convenient as in lemur where you could have numerous monitors showing variable values although at least its something so thanks! 🙂
Back to it 🙂
Whilst typing my problem it caused me to think about the problem in a different way that gave me new avenues to explore – new leads you could say. Anyway, as a result, I now understand I was initialising the array wrong. In fact its not an array at all – its a table so I need to initialise a key and value. So instead of:
S1SeqArray={83,84,86,87,88,89,90,91}
I need:
S1SeqArray={}
S1SeqArray[0]=83
S1SeqArray[1]=84
S1SeqArray[2]=86
S1SeqArray[3]=87
S1SeqArray[4]=88
S1SeqArray[5]=89
S1SeqArray[6]=90
S1SeqArray[7]=91Then
V = programData:getByte(S1SeqArray[0])
Works so almost there.
Thanks for listening lol
Figured it out!!! I noticed that I got a discrepency in the number of bytes received when doing another all pattern dump and looking further, the received message wasnt terminated with F7 and in the OX input monitor at the end of the sysex is a load of CC data – just like when doing a current pattern dump (minus the sysex).
Connected up via my Elektron TM-1 and hey presto. I can dump the current pattern no problem. An all pattern dump sysex message terminates properly as well and gives consistent number of tranferred bytes. So it looks like the Midex 8 is screwing with the sysex…..Or so I thought!
I’ve dealt with sysex before via the midex 8 and not had any problems but I wasnt working with the ER1 on those occassions. I have a SonicCore Scope system so routed the Midi out from the ER into that, filtered out the time clock and then back out of scope and into the midex 8. Works fine now. The Midex was obviously getting confused by all the timing traffic and then unable to deal with the sysex dump properly.
What a voyage of discovery lol. Now if only I could switch off the timing info!!!
Really appreciate your help Possemo!
Cant seem to find any. Soundquest claim to have an editor as part of Midiquest but going by the majority of the internet (it seems!) they make a lot of claims that arent necessarily true!
Despite this and the midi clock issue, the midi implementation seems fairly sound although it would be better if you could address the individual seqeuncer steps via sysex like you can with the Evolver.
Thats what I thought at first but wasnt getting any response when sending that. Then I realised that 3C should actually be 39 because c is the midi channel and the ER is set to channel 10.
When sending F0 42 39 51 10 F7 from the sysex window in Ox, all that shows in the monitor input window is the following:
0003DA80 16 — 89 11 11 10 F 0 Note Off
0003DA8E 16 — 89 00 00 10 C -1 Note Off
0003DA9E 16 — 89 7F 7F 10 G 9 Note Off
0003DAAA 16 — 89 7F 7F 10 G 9 Note Off
0003DABA 16 — 89 7F 7F 10 G 9 Note Off
0003DAC8 16 — 89 7F 7F 10 G 9 Note Off
0003DAD6 16 — 89 7F 7F 10 G 9 Note Off
0003DAE4 16 — 89 7F 7F 10 G 9 Note Off
0003DAF4 16 — 89 7F 00 10 G 9 Note Off
0003DB02 16 — 89 20 7F 10 G# 1 Note Off
0003DB10 16 — 89 7F 7F 10 G 9 Note Off
0003DB1E 16 — 89 7F 7F 10 G 9 Note Off
0003DB2C 16 — 89 7F 7F 10 G 9 Note Off
0003DB3C 16 — 89 7F 7F 10 G 9 Note Off
0003DB48 16 — 89 7F 7F 10 G 9 Note Off
0003DB56 16 — 89 7F 7F 10 G 9 Note Off
0003DB66 16 — 89 7F 7F 10 G 9 Note Off
0003DB74 16 — 89 7F 7F 10 G 9 Note Off
0003DB82 16 — 89 7F 7F 10 G 9 Note Off
0003DB90 16 — 89 7F 7F 10 G 9 Note Off
0003DB9E 16 — 89 00 00 10 C -1 Note Off
0003DBAC 16 — 89 00 7F 10 C -1 Note Off
0003DBB6 16 — 89 00 00 10 C -1 Note OffDont get anything in the sysex display window. Yet when requesting the all pattern dump from within the sysex window, the dump is displayed in the display window (as well as the monitor input window).
I’m beginning to think this is a bug in the ER and it cant actually send the current pattern info.
Love the quick response 🙂
Its definitely time clock F8 because its possible to filter that specific traffic in Midi OX. Once selected it no longer displays.
It cant be switched off at the device – there is a built in midi filter function which gives three options – program change, controller change and exclusive data however none of these prevent it being sent.
I can appreciate what you’re saying about the monitor just been a monitor but it does have a menu for filters which is why I asked. But thanks for the advice re the default setting. The monitor filter thing is only to help me understand whats happening when trying to get the current pattern data so is only secondary. I’ll just use midi ox for monitoring for the ER.
Thanks again – might as well close thread lol 🙂
