Forum Replies Created
-
Posts
-
I’m not sure that’s possible, but on the bright side, there’s a lot of information here that pertains to problems that have already been fixed as OS updates have become available, so it no longer applies.
In the Yahoo group we have been summarizing the outstanding issues and keeping relevant files.
The matter of updating has accounted for much of this forum’s conversation. There’s help at the Yahoo group for accomplishing USB updates, and tips and tricks have been put in documents there.
There were some calls here for threads about how we use Octopus in our setups, but with low forum traffic those threads never really took off. I hope similar ones will, in the mailing list format.
Most of the downloadable stuff from this site is now copied to the Yahoo group–manuals, PDF’s and some images–with the exception of genoQs’ beautiful PDF’s that showcase the different models in photos. Yahoo doesn’t offer enough room for them. I suggest grabbing those for yourself if you are interested, and we’ll find someplace to host them if we have to. They certainly won’t be lost.
Realistically, some people prefer forums to groups. Forums are a more recent phenomenon, but the folks who have been around longer tend to like mailing lists, because conversation comes right to their in-box. It’s the best of all worlds to have both, as we do now.
Your concern is shared, but I think we’re doing all right. If there’s subject matter here you think shouldn’t be lost, alert us in the group, and you or I can do some copying and pasting!
ripe, I tried to send you an email and it came back undeliverable. Can you please get in touch–thanks!!
I’m around! (Octopus New Classic #02 says hi to Rachel!) and I would be glad to help with a revised manual too, if such a project gets off the ground.
Please see the Mailing List thread above, where I point to a Yahoo group for genoQs users. OS and other files could be stored there.
Nicos, did you buy this machine directly from genoQs, or was it a used one?
Did the machine work for you before this problem happened?
Maybe problem is in the flash memory, but if so, this is the first such instance I’ve heard of with an Octopus. I’m sorry I can’t be more helpful.
What happens if you enter the "fis list" command after writing the new OS to flash? See the bottom of Page 10 of the PDF. Does the result look like this?
Octopus> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0x01800000 0x01800000 0x00020000 0x00000000
OCT_OS.elf 0x01820000 0x00010000 0x00070000 0x00010040
FIS directory 0x019F0000 0x019F0000 0x0000F800 0x00000000
RedBoot config 0x019FF800 0x019FF800 0x00000800 0x00000000
Octopus>Have you tried updating using a different .elf file? Have you tried the one on this site?
What happens if you go back to v1.60? The link to that file is the one in the PDF instructions, even though the link URL says 1.62.
The USB update to 1.6.2 is not on this website, but I can give you the .elf file if you need it.
Which model is your Octopus? What serial number? I’m curious about whether it’s an older or newer one. What OS was in the machine before?
Sounds like the machine is functioning OK, which is a good thing–it just doesn’t like the file.
Did you send email to the genoQs guys and get no reply?
Nicos,
Are you using the OCT_162_jk03.elf, with a file size of 304,848 bytes? Be sure your copy of the file is good.
Do you have your terminal program set to send the .elf file in binary format? Look in the settings menu and be sure "binary" is checked. That has been a problem for some people.
Let me know if anything gets better!
Sorry to keep you waiting Nicos, I thought maybe you would email me directly.
Once your terminal program recognizes that Octopus is connected, press and release the reset button. As you know, the terminal should say:
+
RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN – built 04:27:46, Mar 12
2005
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
RAM: 0x00000000-0x00200000, [0x0000cfa0-0x001ee800] available
FLASH: 0x01800000 – 0x1a00000, 32 blocks of 0x00010000 bytes
each.
Adapted by genoQs Machines in 2006 as Octopus boot loader.
== Executing boot script in 1.000 seconds – enter ^C to abort
Octopus> fis load OCT_OS.elf -b 0x00010000
Octopus> go…BUT according to your posting, instead there is a message that Octopus has a problem booting on its own.
Try doing the next step in the procedure anyway:
Hold down the *control* key and the C key on your computer’s keyboard, and then press the reset button and hold it for 2 seconds, then release. Now quickly release the two keyboard keys. This should interrupt whatever is going wrong anyway.
If you see this:
RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN – built 04:27:46, Mar 12 2005
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
octopus – MIDI Control Sequencer OS Update via USB
genoQs Machines, 2008 6
RAM: 0x00000000-0x00200000, [0x0000cfa0-0x001ee800] available
FLASH: 0x01800000 – 0x1a00000, 32 blocks of 0x00010000 bytes
each.
Adapted by genoQs Machines in 2006 as Octopus boot loader.
== Executing boot script in 1.000 seconds – enter ^C to abort
^C
Octopus>(Extra ^C’s are OK as long as the last line is there!)
…then you should be okay to continue.
Complete the last line exactly as below, then hit ENTER:
Octopus> load -m ymodem -b 0x00010000
The Terminal program will let you navigate to the OS file.
Now go to page 10 of the PDF instructions to continue.
Let us know if it works!If you are not sure about any part of the procedure that comes after this, don’t worry–you’ll be able to start over!
Nicos,
First off, you should be sure that your terminal app is set to send data in binary format.
If you do the correct steps to load the OS file in the updating PDF, it should work. Did you follow the instructions on page 8?
– – – – – – – – – –
First, we will tell Octopus that we are about to send something, so Octopus will open a connection and wait for the file to be transmitted. We issue the following command (followed by pressing “Enter”):Octopus> load -m ymodem -b 0x00010000
Send the new OS file to Octopus
With Octopus waiting for the transmission (as we saw above) you should then proceed with sending the OS .elf file using the YModem protocol, supported by your terminal program. To do this, on zTerm we choose the menu “File -> Send Files -> YModem-1k”. Other terminal programs may vary in terminology slightly.When prompted, select the .elf OS file to be sent from where you have stored it locally and press the “Open” button.
– – – – – – – – – –Note that the latest version of OS 1.62 was made by one of our community of users, and contains some post-genoQs fixes, including improved MIDI sync. It’s located here:
http://www.socialentropy.com/studio/OCT_162_jk03.elf
See the forum thread in this section called "multiple h/w sequencers & timing" for the background on this.
I’ll be happy to try to help more if no one else responds!
I’m *extremely* grateful to Ripe for his efforts. Thank you!!
It will be great if the "jk" Octopus OS bugfixes for the 1.62 release can be offered for Nemo eventually.
Here are some notes I saved for my own use about Nemo bugs. Some bits have been taken directly from others’ remarks in the forum. I haven’t been using Nemo often enough lately to be totally up with the details:
••POS Bug, fixed but fix was not implemented by 1.62:
Changing the POS introduces a high pitched note at step 5.
If you change the POS of copied/pasted tracks, the pitch of the 5th step of the ORIGINAL track is transposed up by 16 semitones or so. If you change the POS of the original track, more steps are affected as they scroll to the 5th position.••SYNC Bug: Nemo’s Track 3 goes out of sync after certain mode switches–I have forgotten what it takes to make that happen. Maybe someone else can fill in this info.
••Grid Modes should probably behave the same as Octopus version 1.62_jk02 for consistency (?)
Not sure about status of Nemo re this Octopus observation, how important it is, or what to do about it:
••Track RMX only generates random notes, fixed but fix was not implemented by 1.62.
– – – – – – – – –Robert, I have an idea for Octopus and perhaps for Nemo too, regarding internally automated scale changes, i.e. stored chord progressions that may be applied to saved tracks that are not set to a chromatic scale for drums–which to a large extent follows the model and which Gabriel seemed to like. The idea is taken from my Max-built maxWerk program. I’d rather describe it to you privately and find out if it sounds practical to implement before presenting it in detail in the Octopus forum section. Like Adam’s new Nemo idea, unless enabled, this functionality would be out of sight and out of mind.
