Firmware Improvement Request: Repeat Interval Setting

[Guilherme]

Hi, I just opened a ticket requesting TASCAM to remove the 1.0sec limit on the repeat interval setting.
This limit prevent us to use the recorder as an amazing looper.

I'm currently using the DP-008EX, but I believe this improvement would be useful to other models.

I saw many other users complaining about the same issue.
Ex: https://www.amazon.com/review/R20RDKR6VPU75Y/ref=cm_cr_srp_d_rdp_perm

Please, if you agree with the proposed change chime in to this thread to give more visibility to this request.

Thanks!

----

From my request to TASCAM:

Hi, I'd like to request a very small change in the firmware for this device, which would bring a huge improve for it's usability. The REPEAT feature is a great add to this device, but the fact that there is a minimum interval of 1.0sec is a BIG DISADVANTAGE to it. Can you please improve this setting, allowing customers to set the repeat interval to zero? That would add the capability to this device to be use as an OUTSTANDING looper. I quite don't understand why the limitation on the interval setting, preventing us to set it to lower values. I hope you can accommodate this very small change on the firmware. When researching about it, I saw a lot of other customers complaining about the same issue.

 

[Guilherme]

No one think this would be an amazing improvement to the current firmware?

 

[Phil Tipping]

If it helps, there's a discussion on the DP24/32 repeat here, and @Mark Richards suggested a solution in post #9 using copy/paste. You can position the paste point to an accuracy of 3ms (on the DP24/32 - not sure about the DP008).
I don't have inside info on their design, but can only assume the repeat function can't do a seamless repeat because it would have to re-open each file (one per track) on each repeat, and there is an overhead in doing this. As far as I know, the repeat function is there for rehearsal purposes or for multiple takes when doing an auto-punch, in which case a small delay is acceptable.

 

[-mjk-]

@Guilherme a Digital Portastudio is not a guitar pedal with 1 job. My Zoom pedal does looping and recording but it is all volatile and lost at power off. The DP is a complex recorder that involves playing back from and simultaneously recording to an SD card. My guess is that very slight delay is there for a reason. Most likely because the machine requires a small interval to seek and locate the beginning of the section being looped. It is a repeat function and not designed for looping. Yeah it would be cool but I wouldn't hold my breath because it doesn't seem even possible with the SD card medium.

Of course, there is nothing stopping you from using an external looper and then recording the output of the looper.

 

[Guilherme]

Thanks for the feedbacks folks.

@Phil Tipping I saw that thread, but I was looking for something more dynamic, just to have fun while jamming over some nice recording.

@-mjk- I understand your point of view about the delay, but I'm not so sure about the real impact (I might be wrong).

I'm just playing with some pre recorded tracks here, and I can't see any noticeable latency when playing a track from the SD card. I understand that C/Assembly embedded I/O operations through a SD card might take a few milliseconds but that don't necessarily would be a huge reason to lock the min interval to 1s.

Also, I understand that a looper feature is not what the device was suppose to deliver, but the feature is there and would be a great added value to the device. Specially because there aren't many loopers with the same recording capabilities.

I was only suggesting that change because it's a very simple and small (probably that value is set on some constant/config properties) and by just changing it from 1s to 0s would unlock a very nice feature on this device.

Even if this small change can't be implemented at the firmware level, I think that might be a way to hack the firmware and change that single constant value. I'll spend sometime evaluating it.

 

[Phil Tipping]

Fair point, and you never know, Tascam might be working on it as we speak... as my wife says "if you don't ask, you don't get"
Don't forget, it's not just one track; all tracks have to be accessed in parallel as the ones which are not recording are still needed for playback. At best, they could maybe set it to a fraction of a second, but never zero (for the reasons MJ & I surmised), so they decided to leave the min value at 1 to avoid having to change the display code to handle decimal numbers. Just my hunch though so could be wrong.
Update: just checked the manual and the increments are 0.1s with a min of 1.0s (even though it also says elsewhere the range is 0.5 to 9.9), so I'll revise my speculation and say the min time would be 0.1s, still not zero.
Either way, I've written C code for micros, including accessing sd-cards http://www.philizound.co.uk/plasma/plasma.html so I know that even a 'trivial' change usually involves more than patching a byte or two. It's like suggestions I've seen that it must be trivial to increase the max sd-card from 32GB so why don't they do it!
By all means have a go at hacking the firmware (although we can't officially condone this), but let us know how you get on. I'm sure there are lots of interested parties, me included... but purely for aesthetic reasons of course

 

[-mjk-]

I'm just playing with some pre recorded tracks here, and I can't see any noticeable latency when playing a track from the SD card. I understand that C/Assembly embedded I/O operations through a SD card might take a few milliseconds but that don't necessarily would be a huge reason to lock the min interval to 1s.

Its not about playback latency. Its about going RTZ and then Play. DP CPU is limited. Every time you record, no matter what it is, the DP makes a file. Even if you Undo or "erase" the file the machine has to collate all those snippets of audio files and play them back as a seamless performance. In practice a song with only a few tracks ends up having dozens of audio files that need managing. I just think that they made a minimum to avoid issues.

Also, I understand that a looper feature is not what the device was suppose to deliver, but the feature is there and would be a great added value to the device.

The feature is not there - its repeat, not loop. Of course the repeated section is looped but it is not intended to be a "looper" as the term has become.

Specially because there aren't many loopers with the same recording capabilities.

Are there any loopers that have the same recording capabilities as the DP? It may not be feasible given the track count and SD card medium.

 

[Guilherme]

Do you guys know what is the CPU/Processor/Architecture running on DP-0008ex?
I'm looking to make some tests on hex editing/disassembling the current firmware.

Thanks!

 

[Phil Tipping]

Can't find a service manual for it, but even if you found out, how are you going to do it?
If you plan on extracting the firmware from the chip using the programming pins inside, you'll be able to see what the CPU/MCU is when you take it apart.
If you're planning on decoding and patching the firmware file as supplied by Tascam, won't it be encrypted? Have you tried scanning it and found any meaningful text? I looked at the DP24 file and there's nothing obvious, although I've just scanned some of my own MCU firmware files and there's no text there either, so that doesn't necessarily prove it's encrypted.
None of this may be legal of course so I only mention it hypothetically. Lots of vendors have a 'thou shalt not reverse engineer' warning with their products, although I didn't see one in the DP-008EX manual. Maybe the worst that can happen is you void your warranty, but I'm not a legal person.

 

[Phil Tipping]

Update: just found a service manual.
SCF5249VM140 MCF5249 microprocessor, 96KB SRAM
SCF5250BGA SCF5250 decoder for compressed audio?
M12L64164A-7T 8MB DRAM
S29AL008D70TFI020 S29AL008D 1MB flash memory

 

[Guilherme]

Code seems to be encrypted, Unfortunately, I wasn't able to disassembly it.