[Administrator]

The short answer is yes, you can operate the machine without constratints while it is receiving sysex data.

Before I go to the long answer, I would like to get more specific about the terms used in the Octopus context.
Pages are "containers" of 160 steps each, that are played per default as 10 concurrent Tracks of 16 steps each. There are 144 pages on the Octopus, making up the Grid. The Grid is grouped in banks of 16 pages per bank (a bank corresponds to a horizontal row). At any point in time you can play only one page per bank, so you can have up to 9 pages playing concurrently. Hope this makes sense so far.
There is no notion of a song – that would be the result of your interaction with the machine over a period of time.

Now – you can upload state data to the Octopus at various levels: pages, and globals settings. Pages are play data which you would want to upload while the sequencer is playing.
When you dump out a page, it remembers the position it was at in the grid, so when it comes back via a dump-in, it will replace the content of the page at its old position as soon as the transfer has finished.

So, if you want to replace the current play data, that will work. If you want to replace data that you have played with, but that is not active (pages that are not playing) you can do that on the side, and have other pages play during the transfer. Interacting with the playing pages is always possible, the machine will not lock up during the sysex transfer.

[Administrator]

Dear all,
as a general rule, we do not make official statements about our development roadmap.

However, development of the Octopus OS is, and has always been, very tightly linked to requests received from our users.

Those interested in participating in our beta test for upcoming releases may contact us directly to get involved.

Thanks for your patience,
Gabriel

Post edited by: gseher, at: 2007/09/05 22:21

[Administrator]

Hello lebenspuls,
there was a similar question recently and it turned out that understanding the behaviour required a better grasp of attribute maps and factors. In short, events modify the PIT map factor for the track, and not the PIT offset directly.
Hope that is a useful pointer.

Cheers,
Gabriel

[Administrator]

John, congratulations – and nice work! Looking forward to the document.

If you next plan on building a new mode for playing Pong or Memory or something (just as an exercise of course ) let me know so I can give you the right pointers. Ideally we would get a document out of that as well.

Cheers,
Gabriel

[Administrator]

Hi John,

two quick pointers for you –
The .elf file of the official 1.02 OS can be downloaded from the same place as the .syx. However, it is not linked on the page (to avoid confusion) – use the same URL as for the .syx and change the extension to .elf. That way you are always on the safe side.

The HEAD of the CVS probably contains some work in progress, so its probably not the best choice.

Finally, in the file defs_general.h you can set the number representing the version, so you can label your own and keep them apart.

Cheers,
Gabriel

[Administrator]

Hi John, any more progress on this?

[Administrator]

Hi there,

currently you would have to do it in separate runs.
Best would probably be bank by bank + the GRID settings.

However, watch for two more functions in the next release:
"dump all pages at once" and "dump everything at once".

The latter is the one you are missing right now. Be warned that with a relatively full machine, the dump may take a while!

Gabriel

[Administrator]

Well, a few things can be done already with what is on board.
Instead of spreading things across two pages, just set the repeat value (STA) for this one page to 2 and you are all set.
The page LEN parameter excels at controlling the precise number of steps a page will play before switching, while STA is more coarse-grained.
Hope this is helpful.

In terms of making track 0 the "master" track, sure, it can be done technically, but I tend to oppose it because of the resulting inconsistencies with the rest of the model, such as when you start to build chains that may (or may not involve it), etc.. Interested to hear what other users think as well.

Thanks,
Gabriel

[Administrator]

John, I just sent you the document directly to the address you have registered on the forum. Will take a look at those links tomorow.
Your compiled file looks ok though. Just make sure it’s one you compiled, not the one packed on the CVS.

Cheers,
Gabriel

[Administrator]

Hi John,
the libc is standard and should be part of your gcc package if I recall correctly. Nothing specific you should have to do on that end.

Now, if you have an .elf file, there are a few things you need to do in order to send it over to Octopus. There is no direct .syx conversion – let’s leave that aside for now.

One way to send it over is described in a document you can download here:
http://genoqs.net/downloads/OCT_USB_Update.pdf

Once you have that method under control, you may want to do it in a quicker way – as I do it during development.
This second method is by using gdb (arm-elf-gdb that is). See the .arm-elf-gdbinit file later on for details. In my environment I have set up a build routine in Eclipse so it’s just a key press away.To do it, remember that you need to have Redboot running, and only Redboot (no Octopus code), since this is your gdb stub on the Octopus.

Hope this helps.
Gabriel

Post edited by: gseher, at: 2007/08/23 06:54

[Administrator]

I think the disconnect with the comments may come from people possibly gathering from the demo that Octopus may be some sort of batch processing device

It may be worth doing the same exercise with the machine running so you can actually see how you can get something shaping up to a good result!

Actually you could easily counter that comment about playing in the melody in 2.3 seconds. Just set it to record mode and go..

[Administrator]

You are right – I have moved development across platforms given the same arm-elf-gcc/Eclipse/CDT IDE. Originally started off on SuSE Linux but moved to cygwin because of the many GUI artifacts with Eclipse back in the days. Now happily working on OSX.

OK – the libraries zip file is linke into the downloads page.
You should just unzip and put them in your /opt directory, and point your makefile accordingly.

I’ll be happy to hear whether you got a successful compile or not.

Cheers,

Gabriel

[Administrator]

Hi John,

The documentation for the whole procedure is only partial right now, so if you would like to formally record something written along the way, you are more than welcome to

Basically you are on the right track – however you are missing the adapted eCos base, which contain some adaptations to our hardware. The e7t is the foundament, but we have some deviations in place as well, such as more memory for example.

The most efficient thing to do would be for me to put up the eCos base up for you to download and use. Let me know if that is what you’d like.

Cheers,

Gabriel

[Administrator]

Hi John,

there is – it is a virtual COM port driver that you will need so you can talk to Octopus via a serial connection.
The driver is here: http://www.ftdichip.com/Drivers/VCP.htm

Gabriel

[Administrator]

Hi John, a couple of comments..

Ok, with the slide sorted, I like your suggestion about the parameter show of the pressed step. One fear is that this may produce too much blinking and flashing as you are toggling the steps, but will investigate.

Also, I am not sure if you meant to have the step length display (in page mode) as consecutively lit green LEDs, or if the illustration was not intended that way. In the former case there is an issue since you could not really tell long steps from short steps. Ideas?

Gabriel

[Author]

Posts