MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Ornament and Crime Development Blog
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2, 3, 4  Next [all]
Author Ornament and Crime Development Blog
chysn
If there's anyone in this community interested in this topic, I've started a blog about app development for Ornament and Crime. I couldn't find much information about how to get started, and now that I've gotten started, I'm writing a journal of my progress, with tutorials.

The blog is called "Ornament and Crime... But Mostly Crime," and is here:

http://butmostlycrime.blogspot.com/
rayultine
Jesus, you figured all of that out after 5 days with the module?!

Very cool. I'm excited to see what you come up with!
Sync
chysn wrote:
If there's anyone in this community interested in this topic, I've started a blog about app development for Ornament and Crime. I couldn't find much information about how to get started, and now that I've gotten started, I'm writing a journal of my progress, with tutorials.

The blog is called "Ornament and Crime... But Mostly Crime," and is here:

http://butmostlycrime.blogspot.com/



Awesome. I had started the process of doing some ground-up work with it-- rather than modding the existing firmware, starting from scratch as I'd like to go a bit of a different direction with it-- but this will be useful as well. Problem was, it appears that the display is using DMA and it was not at all obvious from the existing code what I'll have to do from a clean slate to set that up-- and reverse engineering it from the source code is a bit daunting.

At this point, just modding the existing code to add a new app would be a huge step forward...


A first quick read tells me you're on a similar track-- looking eventually to introduce potentially significant new firmware perhaps, rather than a simple expansion of the existing framework. And, my interest is in some unusual sequencing capabilities as well.

I'm on Windows, but I don't see that as too much of a problem...

Also, one thought was to redo the framework such that there could be 4 channels, each of which could be set to do a different function. So one could be an ADSR, another a sequence channel, another a LFO or a quantizer, etc., rather than the way the original firmware switches all 4 at the same time and you can't mix functions...
chysn
Sync, yes, we have similar thought processes about this, it seems.

Some people like it (or, at least, don't mind it), but I think the UI is pretty rough, and I am considering sort of a re-imagining of the software. As I gain confidence in the system that's there, I'm considering a system built on some new principles:

(1) Multi channel operation. You mentioned four channels, but all my thinking leads to splitting O_C into two "hemispheres," with the ability to select a different app per hemisphere. Each app would have access to two CV ins, two outs, two triggers, and one button/encoder. Note that I would not re-implement existing apps. It would be an entirely new system, and each app would follow that I/O principle of being "half" of an O_C.

(2) Screenless operation. The screen would be used for conveying information rather than for data entry. There would be no scrolling through settings. For example, one app might be an LFO, where the knob sets the rate and pushing the knob switches the shape. This would mean that O_C becomes a flexible utility module rather than the complex modulation generator it is now.

(3) CV-based commands. Sending a specific voltage and a trigger could be used to execute commands mapped to voltages. For example, a sequencer could be built with 1V saying "enter record mode" and 0V saying "enter playback mode." Commands can then be executed from a Keystep or Tetrapad, or whatever. This principle goes with (2), in which the screen becomes irrelevant for data entry.

(4) Online help. The current up/down buttons will always be mapped to a help screen that will tell you about an app. The up button shows you what the left hemisphere does, the down button shows you what the right hemisphere does. Holding one of the up/down buttons will let you select a new app for that hemisphere.

Anyway, this is what I'm working toward. It'll be open-source just like the current firmware. It'll be an entirely new product rather than an "improvement." That is, it will hardly do any of the same stuff. So maybe everybody will want two O_Cs!

In other words, my summer is pretty much shot.
Zymos
Number 1) would make me (and probably many other people) very happy!
pld
If anyone does have questions about the implementation, feel free to ping me directly since I wrote most of the core. If something seems weird, I can probably tell you why that is smile

The screen and DAC share the single SPI port, so the core is pretty tightly knit to interleave those and maintain a fixed 60┬ÁS/16.7KHz update rate; it's possible that could be bumped a bit higher but probably not much without sacrificing something. That core, along with the UI events, is mostly decoupled from the apps themselves so it should be reasonably straightforward to upgrade or replace the app infrastructure. Which I've pondered extensively, the current one evolved somewhat ad-hoc out of the original 2-3 proto-apps while the drivers and things were being rewritten, so there are... let's call them residual traces of that evolution here and there wink
sleepgardens
Multi app operation is my dream. For example I would definitely like to use it as half Quadraturia and half Piqued, or half Quantermain and half Harrington 1200. Or maybe I should just get another O_C hihi

Even if you are not planning to include the original apps that could lead to some very interesting developments.
chysn
pld wrote:
If anyone does have questions about the implementation, feel free to ping me directly since I wrote most of the core. If something seems weird, I can probably tell you why that is smile


Thank you for your kind offer! I'm going to IM you now about one thing that's been hanging me up. But my goal here will be to not make you totally sick of me.
Timmy
sleepgardens wrote:
Multi app operation is my dream. For example I would definitely like to use it as half Quadraturia and half Piqued, or half Quantermain and half Harrington 1200. Or maybe I should just get another O_C hihi

Even if you are not planning to include the original apps that could lead to some very interesting developments.


Multi app operation was certainly considered, but the problem is how to map the 8 inputs (4 trigger/gate and 4 CVs) to the parameters of more than one app. It really requires an input mapping matrix covering all the simultaneously-running apps, and the matrix needs to be dynamic to reflect the available parameters for the apps chosen to run simultaneously, remembering that some parameters are themselves conditional on other parameters being enabled within a single app. And all that would need to be displayed on the 128 by 64 pixel screen in a way that doesn't involve a huge amount of scrolling both vertically and horizontally. Feasible, maybe, but not easy and not a trivial task. We decided it was better to direct energy (or at least what's left of it) into an O&C successor which doesn't have the hardware architectural limitations of the current O&C. That's not a criticism of Max's hardware design, btw, just a recognition that the current O&C hardware was not designed with the current O&C firmware in mind - the hardware was designed to be fit-for-purpose for a fairly simple digital ASR (which became the CopierMaschine app after many more features were added to it).

An alternative approach, which doesn't involving throwing the existing firmware baby framework out with the bathwater, is to create combinations or mash-ups of more than one app, where that makes sense. For example, voltage-controlled dual envelope outputs (borrowed from the Piqued app) were added to the Sequins app, so rather than use two of the outputs just for gates, they can also output full envelopes, if desired. The same could be done for the Meta-Q dual channel quantiser app.

Similarly, byte beats from the Viznutcracker, sweet! app were added as an internal pseudo-CV source in the Quantermain app.

Several of the other apps could be mashed-up or coalesced in this way. Obviously not every combination makes sense, and only a small proportion of the possible combinations can or should be done, but it is a relatively low-effort way forward to further evolve the current firmware running on the current hardware.
Timmy
I've added a link to the blog in the hacking subsection of the Firmware pull-down menu on the http://ornament-and-cri.me web site.
Sync
chysn wrote:
Sync, yes, we have similar thought processes about this, it seems.



To a fair extent, yes. But for me, I need the screen for some UI-- selection of some canned patterns, and the entry of custom patterns. I don't necessarily need the quad-realtime display, but would probably make use of it-- separate from app/config operations which is where the UI would come in...

Input-wise, I need a gate/trigger & CV for each "channel", with one output per channel, so the 2-ins 1-out structure of the 4 channels in O_C will work just fine. For many scenarios though, 2 channels will be enough so having the other two channels available for an envelope, adsr, clock divider/multiplier or LFO would be very handy. In my case, I don't need a lot of sharing of inputs across channels-- so I would think the framework can handle the I/O for the channel apps without too much complexity. I see pretty much everything covered on the input side with a gate/trigger + CV and a single output per channel so multi-app seems straightforward enough for my purposes.

Where there would be possibly a little more complexity is in the app config UI, since each app would have its own config and depending on what channel you're working on, could be a completely different program, or another instance of the same program. But I think that should be pretty do-able...

This is pretty exciting, I'm glad to see interest in this piqued-- given I've got two O_Cs around here that I've been itching to play with. Even if we have multiple efforts here that when released, are incompatible with each other, I'm fine with that (especially given I have two O_Cs so I can set them up with different firmware), and would think there is still a likelyhood that we will be able to share information at least, and likely some code where our interests overlap. And no doubt, once things get going designs may morph into something more compatible-- I'd certainly like to make my customized framework useful to other developers who'd like to be able to multi-app on O_C hardware and not have to write it completely from scratch...
pld
Yeah, it was mostly the UI considerations that kept multi-apps from happening. It also seems to invariably lead to self-patching scenarios which means re-thinking things further (it's not the same as external patching; see for example Olivier's comments about the normalization in Marbles). I suspect with a suitably tailored concept and motivation, one could probably even rework the existing firmware and apps into a minimal multi-channel thing in a reasonable timeframe (maybe even a week or two). Even without going the whole nine yards there'd be some interim cleanup/refactoring steps that would make "mash-ups" much simpler to code (and possibly free up some precious flash).
chysn
Today marks the end of my first week with O_C. Here's the next blog post:

http://butmostlycrime.blogspot.com/2018/06/tutorial-pong.html
chysn
Timmy wrote:
Multi app operation was certainly considered, but the problem is how to map the 8 inputs (4 trigger/gate and 4 CVs) to the parameters of more than one app. It really requires an input mapping matrix covering all the simultaneously-running apps, and the matrix needs to be dynamic to reflect the available parameters for the apps chosen to run simultaneously, remembering that some parameters are themselves conditional on other parameters being enabled within a single app. And all that would need to be displayed on the 128 by 64 pixel screen in a way that doesn't involve a huge amount of scrolling both vertically and horizontally.


Well, if you're going to have the current apps, then yes. In my design, O_C Hemisphere, each app will use exactly half of the O_C hardware: Two digital ins, two CV ins, two outs, one encoder, one encoder button. The screen will be split into two 64x64 sections. Hemisphere apps won't have a list of settings to go through so the UI will be simple.

I'm working on proofs-of-concept now, and making a small list of apps to start with. I think I have a pretty good handle on how I/O and interface will be delegated. But it won't be O_C like you know it, not at all. The audience might even be entirely different. I mean, basically, my audience is me. That's the brilliant thing about what you guys have done, is that I can make my own module. So thank you for that.

Quote:
I've added a link to the blog in the hacking subsection of the Firmware pull-down menu on the http://ornament-and-cri.me web site.


Cool, thanks!
Misk
i've still got another uOC to build, and just wanted to say i'm super psyched about this! thanks for sharing!
Timmy
chysn wrote:
Today marks the end of my first week with O_C. Here's the next blog post:

http://butmostlycrime.blogspot.com/2018/06/tutorial-pong.html


I may be wrong, but I think you may have the distinction of being the first third-party o_C developer to actually release working code for an app. Several people have contributed bug fixes and enhancements to existing apps, and several people have described apps they are or were working on, and/or posted videos of prototypes of them, but none, iirc, ever posted code for a fully working app.
chysn
Timmy wrote:
I may be wrong, but I think you may have the distinction of being the first third-party o_C developer to actually release working code for an app.


That's surprising. Developing for O_C is way more fun than for Peaks. I finished a pretty full-featured graphical sequencer today, but I want to do some more QA and make a video before putting it out there.

Meanwhile, here's a tutorial on saving app settings, with a brief overview of the sequencer at the bottom.

http://butmostlycrime.blogspot.com/2018/06/tutorial-saving-app-setting s.html
bgreeves
This is awesome! I'll try to follow your blog. Can you post here when you add new blog posts?
bgreeves
@chysn are your apps on GitHub?
Timmy
chysn wrote:
Timmy wrote:
I may be wrong, but I think you may have the distinction of being the first third-party o_C developer to actually release working code for an app.


That's surprising. Developing for O_C is way more fun than for Peaks. I finished a pretty full-featured graphical sequencer today, but I want to do some more QA and make a video before putting it out there.

Meanwhile, here's a tutorial on saving app settings, with a brief overview of the sequencer at the bottom.

http://butmostlycrime.blogspot.com/2018/06/tutorial-saving-app-setting s.html


The CV input visualisation app looks useful. Perhaps you could submit a pull request against the core o_C code base for an extension along those lines to the existing ADC value visualisation page in the debug facility? See https://www.muffwiggler.com/forum/viewtopic.php?p=2853786#2853786 for details of how to access the ADC debugging page.
Timmy
chysn wrote:
In my design, O_C Hemisphere, each app will use exactly half of the O_C hardware: Two digital ins, two CV ins, two outs, one encoder, one encoder button. The screen will be split into two 64x64 sections. Hemisphere apps won't have a list of settings to go through so the UI will be simple.


I think such an approach also makes a lot of sense, and mapping half of the controls, inputs and outputs to one of two simultaneously-running semi-apps displayed on two horizontal halves of the screen will fit the micro o_C layout particularly well. Not so much the original 14HP layout, but probably still quite usable even without a replacement panel.

Of course, it's not either/or, particularly if running on upgraded hardware with more flash storage, and particularly if your semi-apps leverage rather than replace Patrick's framework, as seems to be the case.
chysn
Timmy wrote:
Of course, it's not either/or, particularly if running on upgraded hardware with more flash storage, and particularly if your semi-apps leverage rather than replace Patrick's framework, as seems to be the case.


Exactly. There are only so many wheels I'm capable of re-inventing. The split app model can definitely be done with the current framework. I just need to finish working out the philosophy and build a nested framework. Two Hemisphere "applets" running at once isn't going to slow anything down, because O_C will think it's just one app running.

Also, I did some proofs of concept with self-patching, and it seems like it's going to work okay.

Meanwhile...

https://butmostlycrime.blogspot.com/2018/06/introducing-darkest-timeli ne.html
chysn
The initial version of Hemisphere is available on GitHub

https://github.com/Chysn/O_C-Hemisphere.git

It's pretty much as I described above: the screen is split in half (64x64), the Ornament and Crime is split in half, with the first two of every in, out, and the left encoder/button going to the left hemisphere and the second two of every in and out, and the right encoder/button going to the right hemisphere.

You start up Hemisphere from the main menu, as it is a regular O_C app with a miniature framework embedded inside it.

The first applets are really simple, mostly proofs of concept, but still useful things. We've got:

Dual Sample and Hold: When a trigger is received at digital in 1, input 1 is sent to output 1, and is held until the next trigger. Digital 2, input 2, and output 2 do the same thing.

Min/Max: Output 1 sends the lower of inputs 1 and 2, and output 2 sends the higher of inputs 1 and 2.

Dual Switch: When digital 1 is high, input 2 is sent to output 1; otherwise, input 1 is sent to output 1. When digital 2 is high, input 2 is sent to output 2; otherwise, input 1 is sent to output 2.

Brancher: When a trigger is received at digital in 1, either input 1 or input 2 is sent to output 1, depending on the probability. The encoder sets the probability. Pushing the encoder flips the current state.

To choose applets, press the Up/Down buttons to choose a hemisphere. A cursor will display around the hemisphere. The encoders then choose the applet for that hemisphere. To leave the editing state, push the Up or Down button again.

It is possible to have the same applet in both hemispheres. In this case, they're totally independent.

I do not have state saving enabled yet. And there's a whole bunch of applets I want to do.

The framework is somewhat similar to the original O_C framework, just basically nested inside it. My framework is more opinionated, though, which is necessary because mine needs to keep track of which controls and which half of the screen belongs to which applet.

I'll be making a brief video and blog post about this this weekend. Right now I have to catch up with Westworld.
Timmy
chysn wrote:
Timmy wrote:
Of course, it's not either/or, particularly if running on upgraded hardware with more flash storage, and particularly if your semi-apps leverage rather than replace Patrick's framework, as seems to be the case.


Exactly. There are only so many wheels I'm capable of re-inventing. The split app model can definitely be done with the current framework. I just need to finish working out the philosophy and build a nested framework. Two Hemisphere "applets" running at once isn't going to slow anything down, because O_C will think it's just one app running.

Also, I did some proofs of concept with self-patching, and it seems like it's going to work okay.

Meanwhile...

https://butmostlycrime.blogspot.com/2018/06/introducing-darkest-timeli ne.html


I haven't had a chance to try your sequencer yet, but I've had a quick look at the code, and it looks interesting. How does the user set the scale (and note mask) for the sequence? I couldn't see any way of doing that, but may have missed something. Also, I wonder if it might be worth offering an option so that the secondary sequence was the same as the first sequence, but offset by a settable number of steps - so, like the CopierMaschine app but just two channels, and using a sequence specified on the o_C rather than quantised notes read from the CV input as in CopierMaschine?
chysn
Timmy wrote:
I haven't had a chance to try your sequencer yet, but I've had a quick look at the code, and it looks interesting. How does the user set the scale (and note mask) for the sequence? I couldn't see any way of doing that, but may have missed something.


No, you didn't miss anything. This is a utility sequencer for modulation, not a quantized one. I basically made it to take the place of my Moskwa, which I had to remove to make room for Ornament and Crime. My next sequencer will be built on Hemisphere, and I plan to take the Braids quantizer for a spin.

Quote:
Also, I wonder if it might be worth offering an option so that the secondary sequence was the same as the first sequence, but offset by a settable number of steps - so, like the CopierMaschine app but just two channels, and using a sequence specified on the o_C rather than quantised notes read from the CV input as in CopierMaschine?


You're basically talking about two independent index points. You know how it goes, I could add features forever. The thing that tells me when to stop is when I run out of controls!
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2, 3, 4  Next [all]
Page 1 of 4
Powered by phpBB © phpBB Group