I’m seeing the most bizarre behaviour from my XF7 today.  I’m in pattern mode and I have 4 patterns/chains loaded.  I go to pattern 1 and record a new phrase, then hit the play button and it plays back fine.  Same for patterns 2 & 3.  Now, in pattern 4 I record a new phrase, then hit the play button, the light above the play button stays on and my XF7 locks up!  The only thing I can do is turn off the power and restart.  This is repeatable!

Here’s the things I’ve done to narrow down the problem. 

First, I thought maybe it was something in the pattern 4 data so I copied pattern 4 to pattern 5.  Recorded the same way in pattern 5 and it ran as expected.  Then I went back to pattern 4 and recorded.  It locked up again! 

Next, I rebooted then went to pattern 4 and ran the clear pattern job.  Then I recorded with an initialized pattern 4 and it ran fine.

Next, I copied pattern 5 back to pattern 4.  Recorded and this time it was OK.  Rebooted and went directly to pattern 4, recorded and now it’s working fine.  File->loaded in a new set of patterns, returned to pattern 4 and recorded, everything is fine.

Anyone else seen any behaviour like this?  Any idea what was happening?  Interesting that once I ran the clear pattern job that pattern 4 returned to normal.  Bizarre…

Sounds like it sorted itself out. There is nothing to prevent the user from entering at least some illogical information. What any program does with illogical information is going to vary. If you are seeking to find what caused the anomalie you will need to closely document your actions during the creation of the data, the transfer of the data, and the specific contents of the data. We are not saying you did not experience what you experienced but it seems to be something that sorted itself out when cleared the Pattern.

If it happens again look for similarities in what you were doing, or the original source of the data. Otherwise, like any software/firmware, backup your work often. And always start with an initialized song or pattern so you don’t inherit things you are not aware of being in the setup.

Also you don’t mention actually looking in the track data (the EVENT LIST) usually a look at the data is all it takes to find the problem.

Bad_Mister - 31 August 2012 10:03 AM

Also you don’t mention actually looking in the track data (the EVENT LIST) usually a look at the data is all it takes to find the problem.

...chicken or the egg...I don’t know there’s a problem with the data I recorded until it locks up the XF so I can’t look at the data :-)

But you do and will know what you are doing at the time it freezes. Inputting system exclusive data, experimenting with whatever… Just make a note of what you’re doing.

After an hour of investigating I narrowed the problem data down to pattern 4, section B, track 4.  I looked at the events and there was nothing unusual.  What I did find was in the F4 Patch screen.  The measure length was set to 40 while the track 4 length was 50!  Another unusual thing was when I went to Pattern->Job->Clear Track and cleared track 4 section C, it did not clear section C, but section B instead.

This actually makes sense in a twisted way.  Track 4 Section B was longer than the measure it appeared in.  Back from my software engineer days, when you store something larger than the memory space you store it to, you get unpredictable results (like a lockup).  When I re-recorded Track 4 Section B, it’s length changed to 40 measures and everything ran fine.

Mystery Solved…

Mutiny in Jonestown - 31 August 2012 06:16 PM

[...] Back from my software engineer days, when you store something larger than the memory space you store it to, you get unpredictable results (like a lockup). [...]

Such an operation should generate an error message, not cause a “lockup” (crash). It seems this should be addressed in an OS update.

Thanks for investigating and posting.

After an hour of investigating I narrowed the problem data down to pattern 4, section B, track 4.  I looked at the events and there was nothing unusual.  What I did find was in the F4 Patch screen.  The measure length was set to 40 while the track 4 length was 50!  Another unusual thing was when I went to Pattern->Job->Clear Track and cleared track 4 section C, it did not clear section C, but section B instead.

This actually makes sense in a twisted way.  Track 4 Section B was longer than the measure it appeared in.  Back from my software engineer days, when you store something larger than the memory space you store it to, you get unpredictable results (like a lockup).  When I re-recorded Track 4 Section B, it’s length changed to 40 measures and everything ran fine.

Mystery Solved…

No, not really. First, I think you meant SECTION LENGTH was set to 40 while the Phrase Length of the data on the track was set to 50. Yeah, so what? That is a possible setting. What happens in this case is the Phrase plays the first 40 measures of the 50, over and over. The Phrase Length is always set by the setting of the LENGTH parameter when the Phrase is recorded. If later you change the number of measures for the SECTION LENGTH, all recorded Phrases will be adjusted (they will play to the Section’s Length and be forced to repeat).

Let’s say you have a very long SECTION and you just want to work on the first 4 measures - do you have to wait for it to cycle all the way around? No, simply temporarily change the (SECTION) LENGTH parameter to 004, now instead of having to wait for the 40 measures to cycle around, all phrases on the tracks will just play measure 001, 002, 003 and 004.

The SECTION LENGTH is easily and dynamically changed at any time. It is the PHRASE LENGTH that requires a JOB to permanently change. The Phrase Length is determined by the Section Length setting at the time the Phrase is created. It would have been impossible to record a 50 measure Phrase if the maximum (Section) LENGTH at the time of the recording was 40. 

But it is totally possible to record each Phrase with a different length, remember that. Most people think inside the box And record all their phrases the same exact length - but like Khan trying to maneuver a starship in a nebulae, don’t always thing 2-dimensionally, you can have each Track’s Phrase set to play a different Length. This is used a lot in dance/trance and other forms of electronic music so that things evolve in expanding patterns of phrases.

If you are happy about the mystery being solved - fine! But just so you know that what you described above is not the cause.

Bad_Mister - 31 August 2012 09:01 PM

If you are happy about the mystery being solved - fine! But just so you know that what you described above is not the cause.

Hmmm...you’re right, it’s not simply a matter of phrase length vs section length.  I brought up the F4 Track view in pattern mode and changed the Track 4 Section B phrase to a different one with a length of 75.  Then I recorded as before and it worked fine.  So I examined the Track 4 Section B problem phrase in the event editor and there’s nothing there but note events, no CC or SysEx messages.  I can’t explain it, but there must be something in that phrase which is very upsetting to my XF :-)

So just for fun, I selected Track 4 Section B and chose record type “overdub”.  I let it run a couple of measures and didn’t play any notes, then I hit stop.  Did my usual record test and no lockup! 

Go figure…

Just tried something else...loaded the pattern and ran edit on the problem track.  Manually deleted every single event in the track and ran my test.  It locked up.  If it’s not the data in the problem track, what else could it be?  What changes when I record with a record type of “overdub” but don’t play any notes?  This fixes the lockup problem every time, but I’d like to understand why.

Look, there are some many things it could be, as I said before. When you place a track in “overdub” Record, you “normalize” any Play FX being applied to the Track in question… So to answer your question, when you remove all the events you can see, there are those that you cannot see… Namely: The offsets being applied by the Play FX! These include Note Shift, Clock Shift, and the parameters creating the swing and real time quantize function.