Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - hangnef

Pages: 1 [2] 3 4 ... 9
Been a month since I've updated so I thought I would.  :)

Making good progress on understanding some of the fundamental things I need to to make changes.

The UI/popup dialogs are much less of a mystery then they were... still awkward and weird how they do it, but I will be able to change these.  The big issue with these is changing large ones.  I'll have to make a copy of the code and do all those address fixups (ugh).  I may be able to inject a function to call so I don't have to do that in some cases.

Also spent a lot of time learning how the MV talks to the xv synth chip and reversing the analog bass mvff file format.

Also, I do not believe supporting a PS/2 keyboard would be easy.  The pins are there, but the input section/graphics library doesn't seem to support it.  I'd need to do a deeper dive to be sure.  How important is this feature?  I personally wouldn't use it, but am curious.

Another thing I looked into was speeding up the USB interface as it is a USB 2.0 chip.  On boot, the MV definitely sets the chip to the high speed setting via its registers.  So, the I/O bottleneck seems to be the disk or FAT file system, not the USB.  If anyone has observed the MV showing up as a USB 1.0 device, then that is interesting to know...

The project speed up changes are working just great, I may do a similar tweak for the library files since those when not used take up a ton of time as well when loading/saving projects.  Not much I can do about the sample loading other than speeding up the disk drive or filesystem code.

I have some dumb questions for those who might own an MC-909 and could answer or test for me:

Is the built in synth better than the MV?  Wondering if it is more than just the bass synth in the MV?  I ask because these 2 machines are almost identical in HW going by the schematics and if there's some synth stuff I can pull over, I think that is do-able.  I did look into whether the MV could somehow support those plug in cards, but the HW pins to interface with those are not present on the MV.  However, they both have pretty much the same custom Roland chips and overall architecture.

2nd, I'm wondering if the Turntable Simulator works like varispeed on a tape machine.  Can you slow down the playback/pitch with the it, record something (say a sample or audio track if the MC909 supports it), and then if you pitch it back up the recorded part would play faster/higher pitched.

So, lots of learning (and questions) going on.   :)

MV-Modifications / Re: LCD on/off switch and silicone 'corks'
« on: April 22, 2020, 11:14:15 am »
You are not allowed to view links. Register or Login
Thanks for the tip re the silicon "cork". Just installed it on my MV today using the material you linked to and what a difference. The pads are now super sensitive and it's much easier to consistently hit them dynamically. The pads now respond more like Maschine pads which is a great thing in my book.

Great to hear, glad it worked well for you!

MV-Modifications / Re: MV8000 mods with pictures
« on: April 22, 2020, 11:13:33 am »
You are not allowed to view links. Register or Login
Great post!

How thick was the silicone in millimeters?


Not sure what the OP used, but I used this (.5mm) and it makes a HUGE difference

You are not allowed to view links. Register or Login

You are not allowed to view links. Register or Login
I'll have to skim back through the previous replies..
Here are my initial 'nice to haves' for the MV-8800:
1) 1GB ram Fully supported, recognised and stable & correctly displayed in all relevant modes.
2)  The Audio track capacity to be either 8 Stereo (Current arrangement) or splittable into 16 mono tracks (Or a mixture of both)...  each fully discrete, pan-able and fully supported across all bus & FX arrangement ... i think the original MV-8000 DID allow for 16 mono tracks, so why Roland dropped this on the 8800 is a proper thumb in the ass decision!
3) This will come down to the HW of the graphics & and how far it can be squeezed???., but if the display refresh latency could be brought down a bit more, that would be excellent..  Esp when displayed on an external monitor.. There is a noticeable lag in the scrolling, esp at higher tempos.. Which can be off putting sometimes.

For #3, are you running your external display at 60hz or 75hz?

You are not allowed to view links. Register or Login
“Varispeed” what is this you speak of???????

Varispeed is the ability to change the pitch of the entire mix, kinda like you would do on a 4-track tape machine.  The MC-909 has a souped up (digital) version of this that allows changing both pitch and speed (varispeed) or just pitch, or just speed.  I've been going over the MC909 code to try and figure out how it is done.

The MC909 has almost the exact same hardware architecture as the MV series, so I'm assuming that one of the chips (the BA or XV) is doing all the heavy lifting here.  It's also possible that the DAC/ADC clocking are being controlled, but I doubt that very much.

I've never used an MC909, but I see code that isn't even relevant to the MC909 in its firmware.  For instance, there is color theming, but it looks like a monochrome display to me.

Howdy everyone, just a little update.

The project saving/loading speed up is done and working (with some caveats).

What I implemented was, if a song is not in use, all of the files related to that song are not written when saving.  This speeds up project loading/saving by quite a bit (there are 23 files written out for each of the 16 potential songs).  So, if you only have 1 song in your project, 345 fewer files are written to disk.  Same goes for loading, 345 fewer files are opened and read.  If you add a song to your project, those files will show up when you save.  I've been doing a lot of testing of saving/loading/renaming etc.  A little more to do, but so far it's working like a champ.

In general the disk I/O is super slow on the MV.  I plan on looking at that in the future, both at the HW level w/ the IDE settings and the FAT filesystem code (which is hideous).

What took so long was trying to get the actual song *directories* to not be created.  This was a HUGE can of worms and I spent the past 4 or 5 months just on that.  In retrospect, it was a colossal waste of time.  I have OCD and it bothered me those directories were there.  To get that working entailed modifying a lot of different places in the existing code (which is super tedious due to the code not being position independent).  Just a ton of extra work for very little payoff.  I backed it all out.  I'll just ignore the empty directories.   8)  If at some point in the future I discover an easier way to do this, I'll implement it.

The only thing I should add at some point is the removal of those files if you delete an existing song (other than the first one) from your project.  As of now, if you remove a song from your project, the files will stay, so project loading/saving will start to creep back to the original speeds with each additional song added/removed.  Worst case would be using all 16 songs and then removing all but 1.  The files can always be removed manually over USB, etc.

Additionally, copying existing projects will not remove unused files.  If you know your project doesn't use the files, they can be deleted and things will still work normally.

I am curious if anyone uses more than 1 song in a project, I never do so this is a huge workflow speed up for me.  It's 1 song per project for me.

There are more optimizations I can do here, but I'm going to move on to something more interesting for my next change.   :)

What's also good about my firmware changes is that I'm pretty confident it won't brick MV8800s.  You can very easily go back to the original firmware (I have done this hundreds of times over the past year or so).  The reason why is because I have not modified the bootloader at all which is what handles installs, etc.  I say all this but when I do make these changes available I will still have to make note that I can't guarantee things and can't be responsible.  But that's the usual way with custom firmware.   8)    ;D

I'll make another post when I've decided what to tackle next!  I really want to implement varispeed, but I have been talking with the fellow who makes the MV-OP1 ADAT card and it seem I may be able to build a circuit w/ MCU to do it in hardware with minimal software changes (if any).

I wouldn't expect disk space to be the issue.  Until you save the project, everything is done in RAM.  Sounds like a bug.

You are not allowed to view links. Register or Login
Do you know what OS Roland are using?  I cant believe that they would develop the GUI framework and OS in house.  QNX was available at the time and supported the processor used.

It does not seem to use an OS, everything is pretty much bare metal, there is a notion of tasks, but I haven't been able to figure out if it is part of some library or OS primitive.  It'd expect to see some strings or sentinal signs of a particular OS.  QNX was great, I used to work with that.  Nice separation of micro kernel and user space processes. 

The libc used on the MV looks very much like newlib. Most of the std routines like malloc, etc are exactly the same, instruction for instruction.

The UI seems to be a home grown thing, but again not 100% sure.  The MC-909 has similar class names in its unpacked code.
I have yet to figure out how the UI stuff works other than knowing where the structures for all the dialogs are populated.  It's a pretty convoluted processes (even de-compiled).

An interesting thing I discovered poking around at the schematic when figuring out all the chip selects.  There is no code necessary for handling rendering to the external display.  The Epson chip they use natively supports this dual display feature.

You are not allowed to view links. Register or Login
I won’t be helpful anytime soon but I definitely want to learn this kind of stuff.
People that rewrite or add functionalities to old synth OS for example just blow my mind !

Definitely worth learning, the skills translate to other areas for sure (especially the reverse engineering).  I just wish I hadn't picked such a complicated device to do mods for, the code is seriously insane.  Firmware on most synths is pretty minimal until you start getting into the groovybox/workstation territory where it is more of a DAW than a synth.    ;D

Back to working on this on a semi-regular basis at night (but not too too much, don't want to get burned out again).  Thankfully the short break didn't cause me to forget everything.  Current focus is to finish the functionality of speeding up project load/save (which will shorten boot time as well).

It is working, but I'm also trying to not create/utilize the files if they are not used which is a bigger change.  Right now I'm fighting a bug where the temp folder/project TEMP____ is not cleaned up properly during a save which corrupts things.  Debugging this is a slow process, but due to the quarantine, I have lots of time @ night to test stuff out.   :)

MV-General Production / Re: Saving on the MV
« on: April 03, 2020, 09:11:36 am »
You are not allowed to view links. Register or Login
Coo coo, just making sure that I’m saving my project correctly. Glad I’m not the only one. I know these files are only 16kbs each, but there’s a lot of them! Lol

Yes, there are a lot, and having all of them slows things down.  I think Roland did it this way so that they could load what amounts to an entire and fully loaded project into RAM so operations would be fast.  What's odd is, things like adding a new song, etc aren't in the performance path (i.e. you wouldn't do this while recording, etc).  So, I'm still confused on the choice to do this.

Hopefully what I'm working on will speed things up, and as far as the songs, the end result will only be files on disk which are actually used in the project.  So, if you have 2 songs, there will only be files related to those 2 songs.

MV-General Production / Re: Possible enhancements/fixes for MV firmware
« on: February 21, 2020, 10:51:35 am »
You are not allowed to view links. Register or Login
What comes first ? Learning language ? Which one ?

The skills I'm using for this project are the C language, and Super H assembly.  Being able to reverse engineer from assembly as well as write new assembly code is a big chunk of the work.  There was a lot of electronics stuff in the beginning, but that stuff is all done now.

MV-General Production / Re: Possible enhancements/fixes for MV firmware
« on: February 19, 2020, 08:56:05 am »
You are not allowed to view links. Register or Login
This is amazing. I wish I could do this kind of thing !

Hehe, I wish you could too!  Help would speed things along for sure.

MV-General Production / Re: Possible enhancements/fixes for MV firmware
« on: February 18, 2020, 08:28:06 am »
You are not allowed to view links. Register or Login
Have you made any progress recently ? This topic is so interesting !

Hi, thanks!

Yes, progressing a bit more slowly.  I burned myself out before the holidays and took a breather for other projects.  I was spending just about every waking moment on this project so needed one.  Back on it though and I hope to have the project load/save speedups wrapped up.  It is working, but I want to do it 100% correctly, not a hack... so it is taking longer.

Making changes is extremely tedious due to having to patch in large amounts of assembly code and handling all of the offsets etc.  I need to automate this or I'll go mad.   :o

MV-General Production / Re: Saving on the MV
« on: January 24, 2020, 08:06:06 am »
Yeah, the entire project (as if maxed out) is always saved.  It's an odd choice, and slows things down a bit (something I'm trying to improve).  The unused files are empty placeholders, but they are still there.

Pages: 1 [2] 3 4 ... 9