- This topic has 14 replies, 5 voices, and was last updated 13 years, 7 months ago by
.
-
Posts
-
Okay, bear with me, it’ll take a while to get to my point.
What I’m proposing is the development of a new Nemo OS modification. If Gabriel and Marcel want to run with this proposal, I’d be delighted, but given the state of affairs here, I don’t expect any support from them in the immediate future. So I’d like to put this idea out to the community, and at the end of the post I’m going to discuss an idea for maybe getting some funding to anyone willing to take up this project.
The idea itself is quite simple, but maybe a little harder to articulate clearly (my fault).
The idea came to me from a Launchpad patch I built in Max For Live. Essentially, on my custom patch, I’m using the launchpad’s columns as a series of track controls. Each column is controlling one track, so in the 8×8 grid, I’m controlling tracks 0-7. However, when this became not enough tracks, I revised the patch to allow one of the buttons outside the grid to flip to a second set of tracks, so that when this second mode is engaged, the matrix is sending control messages to, and receiving feedback from, tracks 8-15. It’s very easy, and not at all overwhelming to deal with. Let’s call this function the "switch set" command.
Then I began to wonder: Does the Nemo have the same "brain" as the Octopus, capacity wise? I suspect that it does because the brain of the Octopus is not exactly a high horsepower CPU (nor does it need to be), and if it’s cheap enough, why would Gabriel and Marcel want to deal with two separate sets of parts? Could the Nemo handle more tracks and pages?
The proposal: A key combo (I’d nominate hold GRID and press PAGE, which I believe is unused and puts it at a very intuitive location) becomes a "switch set" command (afterwards SS) on the Nemo. The SS would function differently depending on if the Nemo was in GRID or PAGE mode when it is triggered.
In PAGE mode, this would function more or less exactly like my Launchpad version. That is, in the current Nemo OS, a page contains tracks 0-3, controls tracks 0-3, and displays tracks 0-3. I’m proposing that a page contains tracks 0-7, and that SS flips between displaying and controlling either set 0-3 or 4-7. All tracks play concurrently, but you can only see and control one half of them at a time.
(There are a couple of technical questions here about how things should work, namely a) Can you chain tracks across the split? b) Does the effector work across the split? c) Does the "SEL" double-click to select all tracks select only the visible track set or all tracks? My opinion is: whatever is easiest to program. But my preference in terms of function and ergonomics would be: a) No. Too hard to control. b) Yes, easy to control, and the Nemo doesn’t have to worry about which tracks you’re looking at. c) All tracks.)
In GRID mode, this would function in a very similar way, but on the larger scale. in the current Nemo OS, the grid displays four banks of pages, and pages 0,0 to 3,15. I’m proposing that the grid be expanded to hold eight banks of pages, and the SS function switches between controlling and displaying pages 0,0 to 3,15 and pages 4,0 to 7,15.
So the current Nemo build is this:
4 banks
64 pages
4 tracks per page
maximum 16 tracks concurrentI’m proposing:
8 banks
128 pages
8 tracks per page
maximum 64 tracks concurrentThere are a couple of things that excite me about this, in addition to the raw increase in power of the Nemo. One is that, if this were a Max patch, it would be very easy to implement. It would involve copying and pasting some existing structures, and adding some gates and switches to route controls appropriately. The second is that this functionality wouldn’t interfere with anything existing. Anyone who never wanted to touch the expanded capacity wouldn’t have to alter the workflow at all, and from my point of view that’s a sign of a good modification. It’s invisible unless you need it.
ANYWAY: So this project is beyond my programming skills. And it is worth something to me, and I think it would be worth something to many Nemo users. So while I’d really be delighted if someone with a Nemo and interest and know-how took this project on for free, I recognize that is time-consuming, and I also wanted to poll the community and see if we could get a pool of money going to help make this happen. I’d be willing to pony up a $100, and I was hoping I could find ten other Nemo users who would do the same to a potential programmer, and maybe if we can get a pool of $1000, we can make this happen.
Of course, if you would want to do this for free, that would be even better.
Post edited by: Adam, at: 2010/08/08 21:41
Oh, and I did discuss this with Robert via email, and he took at the Nemo source code and had this to say:
Quote:But there are problems. First, the code is still totally in Gabriel’s domain, i.e. all the include paths are hardcoded to point to his particular account on his home development machine. When I started working on the Octo sources I found the same problem, and I had the remove all these Gabrial’isms and generalize the code. That’s work.The second problem is that it looks that Nemo’s 4-track interface is indeed hardcoded into the sources, at several places. So tweaking this could result is a lot of problems, testing, debugging, tweaking, etc. While of course it would be possible to change this (I’ve done major surgery in the Octo source tree), it is simply too much work for me right now.
Regarding this first issue, I believe all that is addressed in the development document available for downloading. (By addressed I mean: they walk you through the solution, but you still have to do all the labor.)
The second is suggesting that it will be a bit of work. But think of double-capacity Nemo! Imagine the glory! TAKE THE CHALLENGE.
Great post….and a even greater project to start….
I just wonder about a few things….:
– Your theory sounds great….but is this even feasable with the Nemo hardware….?– Is the memory of the Nemo big enough to program this and keep enough left to work normally…?
– Why talk already about money and the amount of it…even though you do not have a programmer found yet ?
– Due to the fact that the Nemo part of this forum is only visited by a couple of people….getting 10 people to pony 1000 in total will be already very difficult.
Still….i like to hear or see if this is even possible on the Nemo.
And there’s another problem. Where to go with the changes applied to the Nemo sources? A patch like that will easily get out of sync with whatever genoQs adds/changes to the source tree. The best thing that could happen to a large change like that would be adoption by genoQs.
– Robert
Well, Robert, I think if we did get it built, they would adopt it. I just think waiting for them to build it might involve waiting forever. Isn’t that what happened with your step phrases (that was you, wasn’t it?)? You came up with a feature they liked so much they made it a permanent part of the OS?
Prime NL:
1) I’m not sure it’s feasible. I’m guessing the brain (i.e. CPU and memory) of the Octopus are so cheap that they used the same parts in the Nemo, but it’s a guess. Robert, who is more knowledgeable than I, thinks it may be possible.
2) See 1.
3) Because I thought it would maybe help find a programmer.
4) Well, the money is a means to find a programmer. The end of finding a programmer, ten people or no, is the important thing. I can’t see how someone with a Nemo and the ability to do this wouldn’t want it done – Robert is an exception because he happens to also own an Octopus, so it’s somewhat redundant for him. Do you have any suggestions on how to get more attention?
Adam wrote:
Quote:Well, Robert, I think if we did get it built, they would adopt it. I just think waiting for them to build it might involve waiting forever. Isn’t that what happened with your step phrases (that was you, wasn’t it?)? You came up with a feature they liked so much they made it a permanent part of the OS?I wrote 90% of the changes in the big v1.60 OS release. Most of that went in fine, only my phrase stuff got clipped a little (I wanted more phrase presets and a little more control).
So yes, it’s likely that a solid patch will be accepted by the guys. But since we’re pushing the concept behind the Nemo (keep it simple) with this new proposal, I’m not 100% sure in this case.
robert wrote:
Quote:So yes, it’s likely that a solid patch will be accepted by the guys. But since we’re pushing the concept behind the Nemo (keep it simple) with this new proposal, I’m not 100% sure in this case.Well, that’s why I was excited by this:
adam wrote:
Quote:The second is that this functionality wouldn’t interfere with anything existing. Anyone who never wanted to touch the expanded capacity wouldn’t have to alter the workflow at all, and from my point of view that’s a sign of a good modification. It’s invisible unless you need it.It seems to me that you could integrate it into the existing Nemo concepts/workflow/etc. and people wouldn’t even know it was there unless they wanted to investigate.
Adam wrote:
It seems to me that you could integrate it into the existing Nemo concepts/workflow/etc. and people wouldn’t even know it was there unless they wanted to investigate.[/quote]Yes, true. But… if an ignorent user were to trigger the ‘secret’ button combo to toggle to the other set of banks/tracks, and stares at a totally empty Nemo, he/she could think that Nemo lost all the data.
– Robert
cikira wrote:
Quote:For the time being I’d just be happy to see v1.62 compiled with bugfixes for Nemo.What bug fixes did you have in mind, Cikira?
– Robert
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.
- You must be logged in to reply to this topic.