Hey! I cant say really what the problem as I havent experienced this with the PC4. Recently I got given a Pirate Midi Bridge 6 to test which is awesome, but in a new Beta at the moment so havent fully reviewed it yet. I have encountered something similar when sending midi to syntakt to control mod wheel and breath controller when using the footswitches to change other settings at the same time as sending midi cc via expression sliders.
At this point I dont know if its on Bridge 6 side or Syntakt, are you on the latest Syntakt update?
And the artefacts thing is what I experience too when using the bridge 6. When viewing the mod wheel read out i can see it fluttering, but the data been sent from bridge 6 is fine.
Thanks @James_Orvis - itās so bad. My ST has latest OS and Iām closer to believe thatās itās an issue (actually not a bug) with my Syntakt only. I canāt explain why. Maybe a hard Firmware reset does the trick? Not sure. Maybe I need to try a 2nd one to test it.
I ran into some midi issues recently controlling syntakt with octatrack, see these for confirmed details of the bug/s.
Iām not sure how exactly messages for the MW/BC macros are handled within the ST, but if it involves cc mesages sent internally I wouldnt be surprised if our issues are related.
Essentially STās midi implementation is a bin fire. i havenāt heard anything from elektron confirming that they will try to fix it, apparently they arenāt working on syntakt at the moment.
Are any of your macros assigned to amp page parameters? Or filter frequency?
Iād be happy to attempt to reproduce/confirm your bug if you can write clear steps to do so. Tag me if you do so I dont miss it.
Hello,
Iāve found some strange behaviours related with Trig page.
I have the firmware 1.21 on the Syntakt.
1/ The trig page reload doesnāt work completely :
press TRIG [PARAMETER] and modify some settings for the active track e.g. the trig probability, the trig LEN, ā¦, PTIM and PORT.
reload the trig page via TRIG [PARAMETER] + [NO] , the message ātrig page reloadā is displayed but the parameters are left unchanged except the PTIM and PORT.
2/ According to the user manual v1.21, Ā§10.1 page 48, āThe TRIG [PARAMETER] page can not be randomized.ā
However pressing TRIG [PARAMETER] + [YES] doesnāt produce any error / warning display but randomizes the PTIM and PORT values.
There seems to be something special with the PTIM and PORT parameters.
TLDR @timo I dont think your and my issues are related, at least not obviously so. Iād be happy to have another look if you do get around to writing clear steps to reproduce your bug. I really wanted our issues to be related so Iād have more reason to get my bug looked at but such is life!
what I tested this morning:
Setup:
Connect DN midi out to ST midi in. Set DNās first midi track to CHAN 9 to control track 9 on ST.
Select dual vco machine on track 9, with midi channel set to 9(default).
Set track 9ās filter freq to 0.00 and res to 127.
In track 9ās modulation setup for MOD WHEEL, set only filter freq to +127.00
Set amp to infinite and trig the track to get the dual vco droning away.
Go to track 9 filter page, sweep the filter from 0.00 to 127.00 and back. listen.
On DN MID 1, enable MW knob and sweep from 0-127 and back. listen.
On STās track 9 modulation setup for MOD WHEEL, turn the Level/Data knob from 0-127 and back. listen.
Observations:
Sweeping the filter freq on the filter page(step 6) yields a nice smooth sweep as expected from the fine resolution control of the filter freq control knob.
Sweeping the mod wheel from DNās midi track(step 7) to attempt the same filter sweep yields obvious coarse steps in the filter freq value.
Adjusting the mod wheel level with the level/data knob (step 8) from the Modulations Setup menu yields the same coarse stepped sweep seen in observation 2.
After testing the amp parameters with shared nrpn assignments in the same way, I didnt find that they were having the same simultaneous effect as when I previously sent these nrpn messages from OT.
Conclusions:
the stepping is due to the output values of the modulation macroās. they can only have values 0-127 so fine resolution parameters like filt frequency, tune, lfo speed, etc that are assigned to these macroās will have their values stepped out accordingly. thats not a bug but a limitation inherent to mw, bc etc being having limited resolution available. This was further confirmed by setting the macro to control tune, set to +127 you can control pitch chromatically with the modwheel!
according to observations from step 4, the modulation macros dont work by sending nrpn messages, and I dont think they send cc messages either, most likely they send some kind of value offset message to the parameters they are assigned, i hope this helps someone figure out your bug.
just to check, if all 12 tracks are set to receive on channel 1 and you send CC1(MW) to channel 1, then all 12 tracks will respond to the same CC1 valueā¦ a lot of presets have macroās assigned already so sending the same CC1 value to all tracks could have some pretty zany results!
I had a red hot go at reproducing your bug using DN as midi controller and could not! Thatās a horrible bug to be dealing with and I hope it gets resolved!
Have you got a midi keyboard with mod wheel or some other midi device to test with? Iād be surprised if the PC-4 was the culprit, but that could rule it out.
Maybe you could run the PC-4 into Snoize Midi Monitor(or something similar) just to check that theres definitely no weird messages being sent.
If you havent already reported to support, do the midi keys and midi monitor thing first then start up a ticket, only takes a minute. Seems like theyāve got a backlog so the sooner you report the sooner youāll get a responseā¦
The Machine and the Track are irrevelant for the bug/problem, itās affecting sometimes one track, sometimes two tracks, sometimes even three tracks. Itās completely random.
I just set all midi channels in the OT to āoffā, except for Track 11 - which is the controlled Track - same behavior.
I measured incoming midi CC values and channels sent by the Midi controller (PC4) with my MPC One and itās all as expected.
having this same issue now. happened 3 separate times in the last hour. powering off (while the seq was still running) and powering back on helped, but i didnt try the keyboard mode thing. was this ever explained or resolved?
When you do āClear whole patternā:
Tempo and pattern length/scale does not reset to default values.
Keyboard scale and root note is not reset to default.
Nasty bug this morning, could have lost an entire project if I didnāt pay attention.
Yesterday I worked on a new embryo that started to get legs. I started it by loading an empty project and I saved it in a new slot with its own new name.
When I woke up this morning, I wanted to hear the idea with fresh ears (I keep my Syntakt on the bedside table) and when I loaded it, it started to play the previous song I worked on before this one. I checked and it had all patterns of it across four banks. So I first thought that maybe I loaded that project before going to bed?
I then loaded the new project slot and this is where it asks me if I first want to save the changes on that same project before loading. Had I not paid attention to it and selected Yes, I assume it would have written over the new project with the patterns from the previous project. Luckily I selected No, so it now loaded the new embryo that was supposed to be there when I powered it up in the first place.
So thereās still this lingering data ghost bug on there. Iāve had a similar problem in the past where upon booting it up, some patterns were erased. Iāve learned to always reload the project when starting just in case, but this is the first time it not only erased patterns, but replaced then with the contents of a totally different project.
Iām guessing that when a project is loaded, it doesnāt actually erase the data on each pattern, instead it probably just has a flag that indicates whether a pattern is āin useā or āblankā. And then I assume that during power cycles some data corruption occurs that makes those states change - both ways, meaning both āerasingā active patterns and resurrecting unused patterns from previous load states. Kind of like how apps like unerase can recover permanently deleted files from a disk or hard drive.
Did you start the project by creating a new project in an empty slot with INIT NEW or by loading an āemptyā project you created yourself as a template?
But again that was yesterday. And then I saved the project a bunch of times, first time I have it a name and selected an empty slot. Then Func+Save to save every ten minutes or so out of habit. Then turned it off and went to bed. Woke up, booted it and another song was there in ram.
I have noticed a bug with the LFO: I am using an exponential wave with it set to a negative speed (so it goes up/down towards the end and it is flat/0 at the beginning - this is important) and with Trigger One (so it triggers and runs one cycle). The LFO is set to modulate pitch. All my notes are set to not trigger the LFO, so the LFO is not running (it is not being triggered). But when I change the depth it will change the pitch of my synth, although there should be no change (because the LFO isnt running).
> LOAD PROJECT > CREATE NEW
>