I wouldn't worry about OS on an Arduino.

There is the old saying "You get what you pay for.".
Possibly equally old is "There's a sucker born every minute".

The two combine to the much older "Caveat Emptor" -- Let the Buyer Beware!

Honestly, when I hear the first one I say "really? always?". Obviously I've paid for some screwings in the past....

I wouldn't copy the array just to use part of it. I'd set a pointer to the start of the part I want to use then iterate the pointer to the end.

No time to go into detail right now, be back later to see how the thread develops.

--- back again and got more time

Code:

Song::Song(int notesArray, int pin)
{
    _notesArray = notesArray;
    _pin = pin;
}

I dunno what that's supposed to do for you but (int notesArray) is just 1 int no matter what name you give it.

You can set up the array as global or as a data member of the Song class.

If the song is expected to get big then look into storing the song data in flash memory (PROGMEM) and copying short stretches into a small array if not a note at a time.
If you go that way; it takes time to play one note, much-much-etc longer than to copy the next from PROGMEM, at least if you don't waste that time with delay().

This whole part to pack led ON/OFF into the bits of bytesToShift according to 2 arrays of bytes;

Code:

    for (int a = 0; a < 4; a++)
        bytesToShift[a] = 255;

    for (int matrixNumber = 0; matrixNumber < totalNumberOfMatrices; matrixNumber++)
        for (int possibleLed = 0; possibleLed < 8; possibleLed++)
            if (drawLeds[matrixNumber][possibleLed][row] == true)
              bytesToShift[matrixNumber] -= (255 - bytesX[matrixNumber][possibleLed]);

I think you can cut that way down using & and | operations on bytes in the place where you set drawLeds[][] values. You won't need the drawLeds[][] array, just fill bytesToShift[] directly right there and dispense with the code shown above completely.

You might practice with byte-wide bit operations some in code first, printing results in HEX or BIN to make it easier to 'see the bits'. I use unsigned 8-bit (type byte) so the sign bit of type char doesn't get in the way.

byte B = 1 << 3; // B = 0b00001000 ... 0b is binary notation instead of decimal
B = B | 1; // B = 0b00001001

byte A = 0b01010000;
B = B | A; // B = 0b01011001;   | (OR) sets bits, all bits from both get copied to the result

bitWrite( B, 3, 1 ); // B = 0b00001000 ... how to set single bits without using shift as above
// but with shift you can move multiple bits in one go.

A = 0b00001111; // you don't have to put in the leading 0's but they don't hurt
B = A & 0b11110101; // B = 0b00000101;  & (AND) masks bits, only matching bits get copied

These are the same as what you do with

Code:

bytesToShift[matrixNumber] -= (255 - bytesX[matrixNumber][possibleLed]);

only much easier to 'see through' and can manipulate all the bits in one operation if you have bytes prepared.

It will take some time to know this enough to do what I wrote could be done above. Be sure to see how more than just one or two parts work, easier/shorter paths will be apparent even if you don't get 'perfect' right away.
Remember, you already have code that works. Mission accomplished! The rest can be regarded as either apple-polishing or good practice/training for later efforts. In most cases, time spent polishing now should pay off with much greater time saved later.

You need to learn about pointers (and arrays if you haven't) but you're on the right track, IMO.

I see little on pointers (outside masses of forum posts) at the Arduino site, but here's

"A TUTORIAL ON POINTERS AND ARRAYS IN C" that looks pretty complete:
http://pw1.netcom.com/~tjensen/ptr/pointers.htm

Well you can if-else-if-else-if-else till you run out of space,

the idea is that if you have mutually exclusive conditions then why test for them all? If they're not then don't do that.
Sometimes switch-case or another conditional is the way to go... these are things that make arranging logic cleaner, faster executing and less ambiguous.

I wrote code in 78-79 on programmable calculators. One way to know the value of these things is to not have a full set, to learn from what you wish you had and have to make up for. You won't forget soon after that! The TI-56 didn't even have indirect addressing, talk about pain!

Okay Olly, now take a look at 'else' to go with 'if'.

Nope, you're right again.

It's that old thing about full code not being posted that often you point out. 
All I posted about (this time at least) is what I see there.

AFAIK heap shotgunning has been behind a multitude of program/OS crashes for over 20 years now.
It's no mystery to me after seeing the hardware-ignorance-is-good trend in comp-sci long ago.

How many programmers does it take to change a lightbulb?
Can't be done, it's a hardware problem!
Yet who designs the OS?

If everybody with a stock portfolio who is making more than 200k/year is a "job creator" then why not "prosumers" who keep companies able to sell goods/services? Yes, that's right, the same word in English can have more than one definite meaning. Use the roots, etc. While we're at it, everyone who actually WORKS for a living and makes someone else (the job-creators) should be known as "wealth-creators" since after all no one part of the loop makes the money go round much as some politicians would have us all believe.

Just wondering when these will be available:

http://blogs.smithsonianmag.com/science/2012/08/new-device-can-measure-the-mass-of-a-single-molecule/

Unless the button grounds pin 18 with pullup on!

Certainly so. There's the alloc/copy itself every time it changes aspect that makes the String class bad practice on small/tiny memory models and the dealloc/heap-shotgunning that makes it worse.

But when I add up those pieces I see, even without deallocation there doesn't seem to be enough to fill 1k, probably not 256 bytes. If it's a memory crash I would expect more.

+1 to avoid using the String class on Arduino. Use C string arrays instead, they're well-behaved.

if i do this :
  chaine=String(adresse)+" "+String(Valeur)+" a="+String(a)+" b="+String(b)+" c="+String(c);
  Serial.println(chaine);
then bug

What kind of bug? Converting each value to a separate String is completely unnecessary.

In this snippet you have 5 calls to the String constructor (requiring 5 calls to the matching destructor)

Even worse, the compiler is going to typecast the rest into Strings too. Then for every + the String chaine gets copied over as the larger version (chaine + nextString) as a new String and that keeps going on for all 9 parts.
When are the old copies of chaine destructed? Right after concatenation?
Even worst case, I don't see enough just there to fill 1k of ram.

1 line at a time would cut more than 1 of those arrays down by a factor of 8 wouldn't it?

Additional: you could process 1 position at a time to store into a 1 line array in the lightUp function and only shift the bits out when that is full. What you do with drawLeds array could simply be a series of function calls to build the line.

I should mention that I find PROGMEM data retrieve then use does work noticeably slower than using data straight from RAM. My 7 line menu print kind of flows onto the Serial Monitor.

It is quite possible but that's not proof either. Being too sure of hunches can have you locked onto false trails when debugging. For Sure Do Try Things Out but don't get stuck on "it must be this". It's never "that" until "that" fixes the code and even then you might have gotten the wrong "that". 
With simple code the answers are easier to be sure of though. 

-- You could try making a smaller version of your project to check the logic.

-- I notice that you make and fill that drawLeds array then have lightUpLeds() do the whole picture in one go, making yet another local array to do it. You could achieve major RAM savings by shrinking that to process 1 line at a time or even 1 led at a time. Do you really -need- to have everything in data at once? Does every led depend on every other led to determine ON or OFF?

I don't want to work out the what, how and why of lightUpLeds()... it's taking long enough to post this! If you can write it, you can trim it.


======================== some day, maybe now you will want to know what's below ====

-- You could try shifting the const arrays to PROGMEM (have to be compiled into flash, can't put them in at run-time) and copy an element at a time into RAM to process.

Here is a link to the AVR Libc modules page, it's the home of the C++ Arduino is based on:
http://www.nongnu.org/avr-libc/user-manual/modules.html
I have this and other pages bookmarked, couldn't get far without them.

Here is the Program Space module with PROGMEM access functions, etc, spelled out:
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html

You see it takes special functions and pointers to store and read constants in flash.
You can easily fit your const tables, bytesX and bytesY into PROGMEM. You will need to change how you use the data, a good bit of change for a beginner but you should learn as much too.


You need some #includes to use PROGMEM:

Code:

#include <avr/io.h>
#include <avr/pgmspace.h>

Here I have a 7 line menu (80 characters per line) stored to PROGMEM, and a special pointer to get the data with:

Code:

const char PROGMEM usageMsg[][80] = { // all this text stored in flash
  "          Piezo touch sensor tuner.",
  "Adjust vertical; enter W to subtract or X to add, and a number 0-255",
  "Adjust timescaler; enter A to subtract or D to add, and 0-16535",
  "to add 250 to vertical enter W250 in Serial Monitor and press enter",
  "seperate multiple commands with spaces; ex: W25 D240",
  "    ** this message stored in flash ram **",
  "    ** and printed with a 1 byte buffer ** :-P"
};

PGM_P Msg; // pointer into flash memory

The full program stores -every- const char string (not C++ String!) in PROGMEM. It has serial user I/O error messages, etc, as well as the menu.

I made this function to print the stored strings one char at a time:

Code:

void  printMsg( PGM_P FM )
{
  do
  {
    B = pgm_read_byte( FM++ );    // FM++ is pointer math; look Ma, no indexes!
    if ( B )  Serial.print( B );
  }
  while ( B ); // when it reaches the terminating zero, it exits
}

And this function just to print the whole menu:

Code:

void printHelp(void)
{
  for ( byte i = 0; i < HELPLINES; i++ )
  {
    printMsg( usageMsg[ i ]);
    Serial.println();
  }
  Serial.println();
}