For testing only, you can just connect with a clip without soldering. The center is fixed, but if you swap the left and right tips, the operation will be reversed. I thought that it would be possible to check whether the value is normally output on the Positive range, just as the value is normally output on the negative range.

Hmmm after thinking a bit, swapping the tips would not make any difference at all (as long as I don’t use the other unused pin).

I think that pitch bending is possible with the modulation wheel by exchanging the wires connected to the modulation wheel with the wires connected to the variable resistor of pitch bend. I think it is easy to narrow down problem if they have the same conditions.

Same 100K wheel pot

Would you like to remove the solder, leave the center, swap the right and left resistors on the modulation wheel and re-solder?
The front side becomes treble.

Hi, Mastropiero

experimented.
I actually re-soldereirigd it to the variable resistor on the modulation wheel side. Pitch bend worked fine up and down the pitch.
So, the easy way to physically check is that way.
You can check if it is a variable resistor problem.

Reconnect the sheet-shaped cable of the membrane panel.
It seems to have something to do with some MIDI problem.

If there is a problem with the operation of the membrane panel, MIDI connection may not be possible or it may become unstable. If the membrane panel connection is not good, pressing the button may not respond. The difference in behavior between when connected normally and when not connected is clear.

I was able to raise and lower the pitch so easily, so I thought I'd remove the attached spring.
However, it will easily return to 00, so leave it as it is. The sound of the spring is noisy though. The power of my fingers is trained by pitch bend wheel.

I think it is a code related issue, but I have not had a chance to check mine out.

Hi there (@Matrix12x: thanks for pointing me to this blog) - I new to this group and only recently added a P600 to my collection - I am planning on contributing to the project. Please be lenient if I ask and write things which have already been posted 100 times. In relation to the new rnd arp mode (= great, I wish I had this on my Jupiter 4) I have a bug: when I play a single note the OS crashes reproducibly. Has anyone had this? Single note rnd arp is not a use case per se but it easily happens when building a new arp line. Best, Florian

Here's the exact description: I press the ARP assign button twice so that it flashes (e.g. rnd arp mode) and then I press Record to latch notes. I then hold down a single key. The note is played repeatedly while I hold down the key but when I release it (and no other key has been pressed) then the OS crashes.

I haven't experienced any crashes, but I've seen it can slow down.
Check around 52 seconds.
Check around 1 minute and 6 seconds.
The slowdown may have something to do with your crash.

However, it's a nice and beautiful addition.

Thanks Jpro600k for the quick response. I can reproduce the slowing down in the case of the UD-pattern, but I think it is unrelated. My suspicion is that the arp_update function can get stuck in the while loop you modified:

do { arp.noteIndex=random()%ARP_NOTE_MEMORY; }
while
((arp.notes[arp.noteIndex]==ASSIGNER_NO_NOTE) || ((arp.notes[arp.noteIndex] == arp.previousNote) && (lowest != highest)));

But I could also be wrong. Btw: maybe it would be nicer to demand (arp.noteIndex == previousNoteIndex) rather than comparing the note itself (just an idea). Then you can have two equal notes in a row but only if you latched it twice.

Maybe someone in this group would be willing to spare half an hour or so to jump start me, e.g. fitting development environment, useful resources and tools, python script to produce the SysEx file + the background on some legacy constructs.

Greatly appreciated!

I can't remember exactly why I did it that way, but, probably, the note index and the note itself are different in some of the patterns (probably the random one... can't recall right now).

Try the change and let's see what happens.

I set up a Fedora Linux in a VirtualBox. Then just cloned the Git repository, did a 'make', and installed failed dependencies with the standard package manager until it finally was built successfully. The makefile automatically produces the .HEX and the .sysex files that are ready to be sent via MIDI. Gligli made a great job here.

Hi , thanks, that helped. I have made progress, but when using the current state of the repository I had to change the Makefile (had to include seq.h and clock.h which for some reason were not included :-\).

Now I am updating the fw2syx.py to comply with Python 3. This is not trivial. Is anyone active in this blog who knows how the script works and what the expected specification of the syx file on the receiving side is? I am totally thrown by the encode32() function...

Thanks

I just created a temporary environment pointing to the Python 2.7 installation during the building process (by default, the OS uses 3.x).

OK, the message is: don't try upgrading it to 3 and I've put this aside for the moment (I think it needs to be done at some stage, though). I forced the .py script to be run using Python2 *.py in the Makefile. You can install Python 2 alongside 3 and specify which one to use ...

I get a Sysex alright, yeah!

Still, I had to change the Makefile on the repository to include the clock.c and seq.c sources from Matrix12x in order for the compilation to work.

Are you using local versions of the code which differ from the github repository? That would be one explanation for what I get: a much larger Sysex (86KB vs. 66KB of the 2.34 version on git). Also, the code is corrupt, e.g. it plays but controls are wrong, no version is shown in the beginning etc. Is the repository really reflecting the 2.34 status?

The GIT is what I am working from. So it should reflect what is actually going on. I never use the sequencer or the arp, so I prob didn't notice that they were not included. I will fix that when I am back up and running. I'll double check that though..... Yeah, it looks like I never updated the makefile. I was running a local makefile. Thanks for the catch.

I use Python 2.7 for this.

OK, thanks for the clarification. There might be more differences. Maybe you can push your local and working copy to the repository?

Are you using a 64 or 32 architecture to compile?

Btw I get some warning in he assembly, e.g. "... Options to Xassembler do not match ... dropping all -Xassembler and -Wa options ...". Anyone get the same? That might be pointing me to the problem...

Here's a screen shot of my make process with the resulting target sizes based on the latest code (incl. the Makefile update) - done by simply running "make all" in the firmware folder.

Hi there, besides my problem of reproducing your working firmware 2.34 compilation I seem to have corrupted my P600 by loading a self produced SysEx to it. Now I can load SysEx 2.34 (or 2.0 for that matter) with exit code "S" but the synth is broken, with 4 out of 6 voices switched off (and parameter change not possible) and assignment and parameter issues... I saw in the thread that Masterpiero went back to flushing the Teensy by USB. Is it possible that I corrupted it using the SysEx so that this step is necessary?

BTW: I am only going through all this because I have concrete plans for changes to the layout. I think that from a patch design point of view the main architectural limitation is that the Poly Mod is "hard wired" to the filter envelope. I would introduce a choice parameter to modify the envelope wiring, also introducing the option of using an organ type amp shape (on-off) so that the current amp envelope is free for Poly Mod (architecture similar to JX8P). As far as I could see that change isn't too hard. But I first need to solve my P600 problem

It may not be corrupted, the voices might just be off. see if you can turn on the "off" voices.
Use: "From Tape" + "4" (voice select) and then "From Tape" + "5" to toggle the voices ON or OFF.

However, if it is corrupted, use the USB on the teensy and flash the .HEX file.

Hi, thanks. I will let you know when I have managed to get things working again.

Thanks also for updating the Makefile. Apart from the missing dependencies the main difference is, that the compiler optimization is set to 2 (was "fast" in the version before, but 2 was used in the rel 2.0). It would be super if you could "git push" your repository to see what other differences there might be so we can work from the same starting point!

Got mine working again . Was not corrupted (but really dodgy in terms parameter settings).

But basically I realised that I accidently broke a wire connection to the keyboard when I opened it to see what version of the Teensy had been installed (I really only just got the P600) - I thought the missing notes were software related. The "broken" arp was because the sync was set to external... I just soldered it and set the parameters straight and now it's good again. I guess that is just a normal P600 learning curve

But the first "beast" I had compiled from the git repository really didn't work at all even though the P600 said "S" after eating the SysEx. So back to forensics on the repository then ...

I want to create a board using a normal pushbutton switch that has the same function as a membrane panel, I would like to see an actual example like an easy-to-understand photo. Is there any user who created it?
I would like to know specifically which type of switch is used for which button.

Does the external mean MIDI?
If the clock source is MIDI, I don't think arp will work without an external signal. Did you use a hardware sequencer or DAW as the clock source?

Yes I mean MIDI - so the arp did nothing. What I meant by this story is that I though everything was completely broken while in fact (apart from the broken wire) the upgrade only messed up the parameters. In the future I will now thoroughly check the parameters before jumping to conclusions. Sorry for the confusion...

Thanks to John (Matrix12x) for updating the repository on GitHub!

Obviously the fork was created sometime in 2014, so well before the 2.1 RC3 status as of September 2015. Nevertheless the 2.34 is supposed to be based on 2.1 RC3. So I did a full diff on the two repositories in preparation of creating a consistent gapless branch originating from 2.1 RC3. Here is what I found:

1) I can map almost all changes to the new features in version 2.2 to 2.34 (most are also commented inline)
2) There are some changes which appear to be related to optimization or even bug fixing on the last GliGli code which are not clear to me / cannot attribute:
- In [ui.c] the lines 414-417 and line 506
- In [synth.c] the lines 554-563 and the lines 917 to 918

Maybe Matrix12x or someone else who happens to know could give me hint what was behind the above changes?

In synth.c lines 917 to 918 originally forced the vibrato LFO waveform to only be a triangle, so when I updated the code to incorporate the other waveforms, I took these lines out (REM) and added line 915.

Re: lines 554-563, That is there the two LFOs are refreshed.

UI.c lines 414-417 are where enough space was added so that the display can display the new menu options in V2.25 onward. The line that was remmed out was an issue, but who remembers from that long ago.

https://www.youtube.com/watch?v=oVtyOwcQo-w

0:27 mark

Rifftraxed

Hi, thanks, I am getting to hang of this. Maybe you can also answer why you chose to repeat the parameters spVibShape, spVibShift and spVibTargets in load and save operationa with the introduction of PW Poly Mod in Storage Version 12? See lines 401-409 (load) and 460-466 (save) in storage. I would have thought that with v12 only PW Poly Mod should be added!?

I am asking because I want to make sure that I am not barking up the wrong tree.

The connector to which the cable of the membrane panel was connected had a loose it, causing poor contact.
Please tell me the recommended connector.

After all, it was necessary to convert it to a push button.
Not a membrane panel.
I made a new panel halfway, but since the cable on the back is an obstacle, it seems that I need to make a special box and put it in it. Since it is difficult to move the LED, I created only the button part.
The membrane panel circuit has separate paths on the front and back of the actual product, so if you follow the path from the connection contact, you can understand the connection destination.
It wasn't hard to connect to the actual button contacts.
I soldered multiple pins to the contacts on the back of the membrane panel connector. so if I don't need to connect the membrane panel, I think this is fine.
It would be nice if the membrane panel could be connected, but the buttons that are clunky but easy to press are the easiest to use.
After repeating the tests, I couldn't actually connect the membrane panel, which really helped me with the new panel I was creating.
The buttons work perfectly, except that there are no LEDs.
I'm thinking of drilling a rectangular hole in the main panel, cutting it out, and placing the panel, but that's still a plan for the future.
I'm also looking forward to thinking about whether to do it or not.


I've just come up with a way to remove all the folded nails and hold the ribbon with a pin.
If this is possible, I think it will be another survival option. When the connector breaks.
I don't need to do it right now. With a new similar connector, you'll have no trouble.

Looking at the code again, you may be correct. I don't have my P600 right now, its in storage, I recently moved. Once I get that up and running, I'll try it out, unless you would not mind trying that out.

At the minimum I think the lines 408 and 409 (and the matching save lines) can at least be changed to something like:

currentPreset.steppedParameters[spPolyModEnv]=storageRead8(); //

deleting the:
for(sp=spVibShape;sp<=spPolyModEnv;++sp)

This is Progress.
Example
The block on the right does not yet contain the feature name. The numbers were cut out from the membrane panel sheet to make chips and placed inside the button caps.