some recorded tracks are empty

[da.vid]

after no problems for months i now experienced every recording session, that one (selected and) recorded track actually produces empty files. No info at all (I took them to my daw).
I forgot if this started only after the update. This could very well be.

Also, it's always the same track. (I work in the same project for some months now).

[da.vid]

Me again, still hoping for some advise or an answer:
Yesterday I started a new project, mad new track, completely different routing. Very simple, just two tracks.
We recorded a session of 30min. Half way (after 17min) on track simply stopped to record, or to add information to the track, sine the length of the .wav file is the same as the other track's.

So, this stopping of recording or even completely empty files now appeared in various situations and in various set ups.

Anyone had this issue as well?

[Weazel]

Hi da.vid.
May I be curious and ask:
Were you recording both tracks at the same time? Or first one then the other?
Did you sync other gear with the Bluebox?

Please see some of my thoughts posted below.

[da.vid]

Ah, my firmeware is 1.2.7

[Weazel]

Me again, still hoping for some advise or an answer:
Yesterday I started a new project, mad new track, completely different routing. Very simple, just two tracks.
We recorded a session of 30min. Half way (after 17min) on track simply stopped to record, or to add information to the track, sine the length of the .wav file is the same as the other track's.

So, this stopping of recording or even completely empty files now appeared in various situations and in various set ups.

Anyone had this issue as well?

Yes, I've had a similar issue.

The setup:
I used a drum machine (master clock) sync out converted to Midi clock into Bluebox (clock slave). Due to the nature of the specific drum machine (Boss DR-110), the clock was not precise. I reckon the master clock (from drum machine) drifted some. Of importance as well, i gathered, is that Bluebox as you all know have a BPM setting.

What I think caused the issue:
The issue I had seemed to occur when the math didn't make sense to Bluebox: That is, when the following three does not ad up: a) the bars:beats from master clock (external), together with the b) BPM setting (internal) as well as c) actual time passed (according to what i guess is an Bluebox internal clock). So much for what I figured had happened.

The issue:
As i recall, the symptoms were the same as you describe: a long .wav that goes silence long before expected. I lost quite some work and a fair share of creative momentum due to this.

The workaround:
I had to let Bluebox continue recording far longer than i thought would be necessary (as I recall double the actual time or more). Not really a positive factor when it comes to creative drive and momentum. Also, it makes Punch in/Punch out not to really work as it ought to.

Alternate workaround (not applicable):
Now you might ask if the problem would disappear were I to switch the roles: making Bluebox the master clock and the drum machine running slave. Importunately, that is a luxury not available at all times and a for all setups. In the case I've described, it simply wasn't possible. I would have had to physically modify the drum machine far beyond my comfort zone and time given the project. (The DR-110 does not have sync in or any other i/o for going clock slave).

Quick fix (not applicable):
Setting a "fake" BPM in Bluebox to make the issue magically go away? Not applicable, since i need the Bluebox to alternate running master clock as well during the same project, eg several recording takes/sessions. Also, I am running the Bluebox FX and I want to be able to use eg the echo in sync with the rest of the project. Faking BPM would make things too complicated in the work flow.

What I wish was the solution:
I wish Bluebox did not clip the recordings mid-file when clock slave and the time math is not acting as expected.
I wish Bluebox was fully rigged with logics to handle clock anomalies when running slave (and I still hope it is, believe me, but I just can't ignore that all my testing tells me otherwise).

The issue is repeating.
I have yet not find any other report describing the issue apart from what you can read in this thread.
Firmware: several. Last known issue I think I was running 1.2.6 (or perhaps 1.2.5, I didn't make a record of it). I have 1.2.7 installed but as of yet I've not tried running a setup or modus operandi similar to the ones described above.

[Steve]

I wish Bluebox did not clip the recordings mid-file when clock slave and the time math is not acting as expected.
I wish Bluebox was fully rigged with logics to handle clock anomalies when running slave (and I still hope it is, believe me, but I just can't ignore that all my testing tells me otherwise).

Help me understand how (exactly) you have determined this. What are your tests?

[Weazel]

Sure Steve! I'd be glad to give it a try!

First and foremost:
Please be patient as English is not my first language! I therefore find myself using many words in this complicated matter, in order to be able to come out as understandable.

Now, let me have a go at recreating one of my tests! The test I've chosen here is one I think easy to recreate. I recreated the test today. You need a stop watch, the Bluebox (of course), an sequencer with Master Clock and a synth/drum machine. It goes like this:
- Connect the sequencer (with Master Clock): Midi out to Bluebox Midi in TRS. Connect the synth/drum machine to be sequenced by the sequencer and audio to be recorded by Bluebox.
- Set BB internal BPM to one value, say for instance 120 BPM.
- Set an external sequencer, I've used Beatstep Pro for testing, to another value. Say 140 just to make the phenomena clear, even though it is substantially different.
- Prepare the stop watch for timing the test recording, in order to get useful results.
- Start the watch and at the same time start recording

o Start the recording using Record button on the BB and the play button on the sequencer running Master Clock.

- Now I let it roll for a while but, importantly and in order to make the result clear, I run the recording for a fixed amount of time.

o Might I recommend the following: 27½ seconds, which would yield just over 16 full bars @140 BPM according to this converter [link]

- Stop recording after 16 bars, 27½ seconds.
- Playback the recording.

The recorded audio file is now incomplete, ending prematurely, in my tests.

Now, a comment on the test above:
The tempo discrepancies used here are exaggerated, but this is to make clear the issue. The problem does of course occur with smaller tempo deltas when recording elapses over longer time period. The important factor being Master Clock being on a device other than the Bluebox.

End remark about my tests:
Let me be point out that I recreated the test today and the problem did make itself observable. I've done a fair amount of different tests in hopes of making things work. I wish of course that I had video documentation of all of them! However my intentions with earlier testing was primarily to enable my setup to function (see the description of the work around i reached in my previous post above) and, until now, not to reach out to the forums. Hence not exact documentation available, as I hope you understand, however unfortunate since I've spent many hours testing.

I hope however you find this test description useful, and that you would choose to run it yourselves! Please ask if further clarification on the test method is needed and I'll try to answer. I've tried to be as clear as possible, writing this does take quite some time for me to formulate. I recreated the test today using this exact method, and I hope you appreciate the effort takes quite some time both in setting up and to describe. I hope the above would be sufficient! Sincerely
/Wesslan


[Edit: This test session was done in firmware 1.2.7]

[Steve]

This is good info. I will look into this today. Thanks for reporting (please try to send a video).

[Weazel]

Thanks Steve! Sure I'll contact you directly if I record a video. Glad to be of help if this turns out to be helpful!

[puffycaps]

This seems like the same known bug, variations of which have been reported several times on this forum. Here is one: https://forum.1010music.com/forum/pr...hile-recording

[da.vid]

Just for the info:
my recordings were empty and interrupted (the data, not the file!) without me playing with any bpm settings or external clocks.
Any suggestions?

[Steve]

We can't make suggestions without more information. How much free space was available on your microSD? How and when do you / did you last format that card? How many tracks are you recording/playing back? Explore the Save As Template... option. Maybe working in the same preset for months is the issue.

[da.vid]

Hi Steve, You are right, I was a bit unspecific.
- SD card: I got the "Samsung PRO Plus micro SDXC 128GB" in May this year, at which point I formatted it according to what was suggested in the forum
- I am running the latest update on it.
- I had deleted former recordings, so it has many GBs free.
- The issue occurred on various occasions, different projects with a variety of tracks (for example 8, all fully used, or 4 and only 2 of these used).
- no play back at the same time.
- all tracks were armed.
- in one occasion, it was always the same track, that contained no data . It did for a while, then one time stopped midway and then never recorded again.

[Steve]

What does "latest update" mean? Please always refer to firmware by its number. I need information that might lead me to see what you are seeing. I still need more info. maybe consider uploading a video or some other documentation. Also, please reform your card often. Consider a SanDisk Extreme Pro A2 128GB or larger as these seem to perform the best in bluebox.

[da.vid]

Hi Steve, I thought you had seen my message from here above, where I wrote that my firmeware is 1.2.7.

I def considered the SanDisk in May but it was really hard to find in the EU and so I asked in the forum about the SD cards here, if the Samsung could work. Has the exact same specifications. You think I should change once more?

I will also do what you said: format my card again (how often you mean we have to do it? Like after each session? So much work... 
I will also try to make a video. Bit hard to film, because it is really just missing data within the wav files, nothing during the handling with the bluebox that would not work (this problems I had before I bought the Samsung card, that it would stop all together to record).

Here two picture of how the recordings looked in my DAWs, once an 8 track recording with track 4 suddenly stopping (or actually falling to a sudden low in dynamic) and then never coming back, and a 2-track recording with track 2 suddenly stopping to save the recorded data.

[Steve]

I did not see that particular post. Thank you. Looking at your photos... it looks like the first recording on that track was good - and only takes were silent. Is this always the case?

Please also share your REC settings or Pre/Post, etc.

The Samsung may have the same basic specs but the important spec is the A2 and the size. A2 cards are better at streaming data in real time. 128GB and larger utilize larger write chinks and this helps bluebox. The SanDisk Extreme Pro A2 128GB is still the best overall performer in bluebox.

[da.vid]

thanks steve.
I will make a little video one of these.

And yes, you are right: it was good till one point (not sure if it came when updating) where it started doing this. It is also always only one track that suddenly stops recording (or at least stops adding data to the file).

About the SD card: mine is also A2. Really same specifications. But maybe it has other differences, that I don't know. Will go for a SanDisk. (here a picture of my alternative:

[puffycaps]

This might not be the problem, but also check your pan settings when recording. If you pan to the right in post fader when recording the signal disappears. See here: https://forum.1010music.com/forum/pr...l-not-recorded

[da.vid]

puffycaps THANKS! Oh yeah, that is exactly what had happened!

I am so glad (even thou with a slight disappointment about the very fact and the lost tracks) that this is not a hardware or, maybe worse, own-brain-ware problem.
And that I now know about it. I could easily reproduce it, even with stereo tracks (where only one half then disappears).

Let's see how often I will run into it again, when in the heat of a session. Pre-fader is an option of course, but in some cases you want to freeze your decisions of a live gig.

Anyways, thanks again for pointing into this direction.