Longtime sysex fader issues...

[beej]

Ok, I've had many sysex fader issues since LP8 (as referred to in another thread) and wanted to share some of these to get some feedback and others experiences.

 

Basically, sysex faders for me have been essentially broken and impossible to work with since LP8.

 

Let's start off with something simple (there is more to come):-

 

I set up a sysex fader in LP 7.2.1, with a sysex string with an MSB/LSB, Roland checksum format, like this:

 

http://dl.dropbox.com/u/4211158/logic/syxfader/lp7.jpg

 

This works fine, and some examples of the output strings including the generated checksums are:

 

Value 0 (strings all in hex btw)

F0 41 10 00 59 12 10 00 06 11 08 00 00 00 51 F7

 

Value 1

F0 41 10 00 59 12 10 00 06 11 08 00 00 01 50 F7

 

Value 2

F0 41 10 00 59 12 10 00 06 11 08 00 00 02 4F F7

 

Value 99

F0 41 10 00 59 12 10 00 06 11 08 00 00 63 6E F7

 

All checksums correct, everything fine.

 

I load that exact project into LP8 or LP9 (I'm using 9.1.3 here, but like I say I've had broken sysex faders since LP 8.0.0).

 

It always outputs the following string, regardless of fader value:

F0 41 10 00 59 12 10 00 06 11 08 00 00 00 00 F7

 

It also even looks wrong in the sysex fader message window (however, I have numerous redraw problems which I will document later, so you cannot rely that the window is drawn correctly):-

 

http://dl.dropbox.com/u/4211158/logic/syxfader/lp9a.jpg

 

So - do you guys get the same thing? Is this a known issue?

 

You can download this project here to try if you wish:-

http://dl.dropbox.com/u/4211158/logic/syxfader/lx_721.lso.zip

[Audiogrocery]

Hi,

 

Can you try just a simple test...

1. Create a new Sys fader and create a track for it or cable from the Input path.

2. Open the Sys dialog, select the "Create" tap, and enable the "IN Bush" capture button. DO NOT set any checksum, value or position yet.

3. Send a Sysex message from your hardware device. It must be Captured in the Sysex fader. Do not set manually ANY checksum, value or position - Logic must care for that!

4. Leave the message selected and close the Sys Window.

 

Try the result.

 

My idea is to leave the Capture processing as it is and do not try to set manually any checksum, value or position. As I mentioned previously in another post a few days ago, the sys faders are rock solid after L8.0.2...

 

A.G

[ski]

I wonder if this could account for the numerous reports (including mine) that some sysex bulk dumps, while recorded (presumably) correctly in a track in Logic don't play back correctly? Case in point: Roland JV-2080. Recording bulk dump info is no problem (natch). But playback into the JV immediately displays an sysex data error message in the JV and the internal sounds become garbage. (Funny that, even with bad data it manages to write it's internal memory and mess things up).

 

However, I've never had this problem playing back recorded (and much shorter) sysex strings from both a Korg Oasys and a Kronos. Though I don't think length of sysex messages has anything to do with it... I think it might be that Korg sysex data doesn't utilize checksums whereas Roland devices do (?)

 

Anyway, just a (possible) aside. Or maybe relevant?

[beej]

Can you try just a simple test...

 

I haven't tried this yet, so I don't know whether this works or not (and I will) - but regardless of whether it does or does not, that is not my issue. Are you saying that you get the same (broken) behaviour with the procedure I described here? Or not?

 

As I mentioned previously in another post a few days ago, the sys faders are rock solid after L8.0.2...

 

Clearly you have a different idea of what "rock solid" means than I do , because sysex faders have been basically *impossible* for me to work with since LP 8.0.0. What takes seconds in LP 7.x is impossible for me to do in LP8+, which is why I have been so frustrated with them... and I can't even go back to 7.x, create the sysex fader there, and import it into LP8+ because of issues like this...

Edited June 20, 2011 by beej

[beej]

I wonder if this could account for the numerous reports (including mine) that some sysex bulk dumps, while recorded (presumably) correctly in a track in Logic don't play back correctly? Case in point: Roland JV-2080. Recording bulk dump info is no problem (natch). But playback into the JV immediately displays an sysex data error message in the JV and the internal sounds become garbage.

 

Possibly, but I don't think it's related. I have seen a few reports about dodgy sysex issues bulk dumping issues (probably mostly from you, thinking about it) but I haven't had the same problems (although admittedly I do far less bulk dumps than I did back in the day).

 

From what I remember (though I will check again), I can record and play back various bulk dumps to my XV5080 just fine, without problems.

 

And if there was something broken with some generic checksumming code that Logic uses for sysex faders, it shouldn't apply to bulk dumps because Logic doesn't create checksums for those, it just plays out the recorded bytestream as is.

 

In your case, have you tried to work out where the issue is (ie, is the data being garbled during recording (so the data captured is wrong), or on playback (so the correct data is output incorrectly)..?

 

However, I've never had this problem playing back recorded (and much shorter) sysex strings from both a Korg Oasys and a Kronos. Though I don't think length of sysex messages has anything to do with it... I think it might be that Korg sysex data doesn't utilize checksums whereas Roland devices do (?)

 

Dunno. Like I say this is just the first problem I wanted to see if others could verify. I haven't seen many reports since LP8 about the sysex faders being bad which surprises me because they are so incredibly bad for me - and when I see reports like Scandor's, someone who spends a lot of time in the environment, saying they are "rock solid" I get even more confused...

[beej]

Can you try just a simple test...

 

1. Create a new Sys fader and create a track for it or cable from the Input path.

2. Open the Sys dialog, select the "Create" tap, and enable the "IN Bush" capture button. DO NOT set any checksum, value or position yet.

3. Send a Sysex message from your hardware device. It must be Captured in the Sysex fader. Do not set manually ANY checksum, value or position - Logic must care for that!

4. Leave the message selected and close the Sys Window.

 

Try the result.

 

OK, I did this, and the sysex message string is recorded by the sysex fader correctly.

 

Of course, this useless in practice as the VAL is wrong and no checksums are created by the fader (and as soon as you play with those to get them to work as in LP2-7 is where the frustration sets in, because this never worked in LP8 as far as I can see).

 

Any other suggestions?

[ski]

Possibly, but I don't think it's related. I have seen a few reports about dodgy sysex issues bulk dumping issues (probably mostly from you, thinking about it)...

 

FWIW, I've seen posts by other people who have had the same problem, to which I've responded. Anyhoo...

 

And if there was something broken with some generic checksumming code that Logic uses for sysex faders, it shouldn't apply to bulk dumps because Logic doesn't create checksums for those, it just plays out the recorded bytestream as is.

 

True enough.

 

In your case, have you tried to work out where the issue is (ie, is the data being garbled during recording (so the data captured is wrong), or on playback (so the correct data is output incorrectly)..?

 

LOL! Who do you think you're asking? LOL! Seriously, when I have a problem like this I test it to death. In this case, death came in the form of trashed programs in my JV. But I think your point about playback not having anything to do with checksums is spot on, so, "never mind".

 

The only time I've had trouble with sysex faders is trying to get them to consistently display note off messages, but that's not germane to what you guys are talking about. So I'll sit in the sidelines and laugh. I mean "watch this thread develop".

 

[beej]

True enough, ski. I was just asking to clarify when I go looking into things - cause and effect and all that...

 

But definitely, a working sysex fader in 7.x that's loaded into 8.x and then doesn't behave the same is clearly broken behaviour. And it was like this in 8.0.0 and is still the same in 9.1.4...

[ski]

How about 8.0.2? Just asking because 8.0.0 was notoriously buggy (as you prolly know).

[beej]

Sorry - I meant, it's been like this *since* 8.0.0 (all the way up to now).

 

Basically, I remember I'd had LP8 for a few months and generally liked it, and I had to do a simple sysex fader task, just creating a simple sysex message, like I'd been doing for years in Logic, and after half an hour of trying to get a 10 byte message string working as it should, I threw my mouse away in disgust and frustration, loaded up LP7.x and did the task in about 30 seconds.

 

And every once in a while I go to check new versions, thinking it must surely be fixed by now, only the find nope, it's still hilariously broken, and no one else seems to have noticed it (on forums I mean, I haven't yet filed a bug report - one of the points of this thread is to clarify these issues I've been having, factor in info from others to see whether they have the same issues, and make a bug report. At least then I can see whether it gets marked as a duplicate and therefore that they are already aware of it).

 

It seems that evironment bugs in general aren't the highest level of priority for engineering, going by past experience. Perhaps this means a rewrite is in order for the next Logic, or perhaps it just means that the environment isn't particularly important as a feature anymore. Perhaps it doesn't mean anything. All we can do is investigate, and report, and find workarounds in the meantime...

[ski]

Redraw anomalies abound here... (8.0.2 on PPC Quad, 10.5.8 ). Here, "Position" was set to Auto, Last -4, and Last -3 respectively. But the displays only looked like this if I clicked on the sysex string data. When I click on the background of the event list, the bottom row goes to 0 0 0 0 0 -EOX+ every time.

 

Anyway, that's all I (truly) have time for atm, but I can at least confirm the screen re-draw anomalies for you.

[beej]

Yeah, horrible redraw issues here as well - I'll get onto them - but thanks for confirming them...

 

The redraw issues basically make it impossible to enter the correct sysex string, particularly with sorting out the placement of the VAL and SUM bytes. You basically have to do it blind and sit a monitor on the output to see what bytes the fader actually sends and go back and try and make the appropriate adjustments - which also doesn't help when the checksum code seems to be broken (at least in the case of the Roland checksums, I haven't exhaustively looked into this yet.)

[Audiogrocery]

at least in the case of the Roland checksums

 

I see, though I do not have such problems say with my vintage Roland Alpha Juno.

 

Did you try to patch an environment fader to a transformer object set to "Sysex Mapper" template, just to check if this gear will work for you?

I did this way during the "broken" sysex fader times. Just an idea...

 

A.G

[beej]

Did you try to patch an environment fader to a transformer object set to "Sysex Mapper" template, just to check if this gear will work for you?

I did this way during the "broken" sysex fader times. Just an idea...

 

I haven't yet, but that's basically what I am going to have to do as a workaround, yep.

 

How do you work around the redraw issues, Scandor?

 

at least in the case of the Roland checksums

 

I see, though I do not have such problems say with my vintage Roland Alpha Juno.

 

So the checksum "Roland" format works ok for you in this case, then? What is your VAL setting, a single byte, or an MSB/LSB combo etc? And position settings etc.

 

Can you give me an example sysex message that works, so I can check in LP7 and LP8+..? Thanks,

[Audiogrocery]

What is your VAL setting, a single byte, or an MSB/LSB combo etc? And position settings etc.

 

As I mentioned before I leave them to Auto, and checksum to OFF and it works quite well with the Alpha Juno. As well as I do this way with my Yamaha SW1000 (having 1000s of sys parameters) which is digitally "ribon" connected to 2xDSP Factory2416 cards on an old PC machine so the mothers DS2416 process and bring multichannel digital audio to my Mac(s) (i.e I control the SW1000 midi devices, editors, FX using only Sysex messages and "Custom Environment editors" via L8/9 and it works quite well too.

 

Can you give me an example sysex message that works, so I can check in LP7 and LP8+..? Thanks,

 

Right now I'm away of my equipment but just found out an old LSO experiment with the Alpha in my mobile computer. So it is better for you to open this LSO in L7, and the new L8/9.

This experiment (just a few parameters) is named "Twin Sys Faders Editor". I developed this technology so you can draw or record CC data and edit it easily in the hyper-draw for example. So you will note that I use two pairs of Sys faders to be able to make that trick. The advantage of the "Twins" is it can receive both (Sys and CC data) and when you mouse automate the Sys Editor fader the recorded automation of the Editor macro track is CC not Sys which is easier to edit. Something similar can be done with a Fader(s) and "Sysex Mapper" transformer(s) as well.

 

You can open any of the sys faders and get an example message. Get the LSO in the attachment below.

 

A.G

alpha_twin_editor.zip

[beej]

It's ok, you've already said you are not using checksums, so there's no point.

 

The reason I asked is because I thought it was likely your Roland device used Roland format checksums in the message strings - it's usually the case, but not always (Roland have been fairly consistent in their sysex specs over the years though) - and if it was the case, and yours was working, I wanted to recreate that here to verify the checksumming was working. As you're not using checksums, it's a moot point. Thanks anyway.

 

I understand that if you don't use the broken stuff in the sysex faders, they work fine ( ! ). My problem is the *other* stuff is broken, there's quite a bit of it, and that's the stuff I need.

 

As you seem to report no real problems for you in your practical use (did you see my redraw question BTW?) I'm assuming you tend to use the "IN" function to capture incoming messages and don't do much actual editing in the sysex fader message window? And you don't really use the checksum and positioning functions much either?

 

Because the redraws of the window are so broken it's impossible to work out which bytes you're changing - at least here, and ski also observes the same behaviour (the redrawing of the bytes changes as you select/deselect the message, and VAL and SUM displays jump around randomly, overwriting bits, and changing a number you think you're changing is actually changing some other number and other similar oddities.)

 

So - working syx faders loaded into LP8/9 break, the checksumming function doesn't generate correct checksums for at least one checksum format, the VAL and SUM and positioning stuff doesn't seem to get worked out correctly and the window redraws are so messed up that it's basically impossible to use the sysex editor. It's not exactly a ringing endorsement for "rock solid", is it?

 

But alas it seems I'm mostly singing about this alone, so I'll document what I can and report it, and go on either finding workarounds or just leaving them alone again, sadly enough...

[Audiogrocery]

I see what you mean. The checksums can be the broken stuff etc. As I do not use them I do not have any problems.

 

I still offer you to try with Sysex Mapper Transformer. I just found out an old Editor project I have made for the Alpha using Sysex Mapper Transformer and its checksum is set to Roland as you see in the pic below ( Probably I had to set that and I was working as far as I remember ). Cause there was a problem with Macro size limitations in the older Logic versions I have designed just one "Sysex Mapper" transformer (to save Kb room). This universal/global transformer worked as "Float point" so I have programed additional ID transformers which send 2 messages - Parameter ID and Value controlling the "Float points of the Sysex Mapper - bytes 7&8" In this scenario byte 7 is the parameter and byte 8 is the value.

 

I may say that I totally failed in this Editor version cause of using this "Universal Sys Mapper". It works fine with mouse control but all Environment Editor parameters are programed for external CC as well. In this scenario if you tweak a few parameters in the external controller then the Universal Sys Mapper makes understandable gabs in the data cause of data toggling.

 

I failed cause of the Macro size limitation programing just one Sysex Mapper.

Now there is not such limitation (there are a few extreme conditions I have found lately) so you can try to create separate Sys Mapper Transformer for each parameter you what to control. The remote (Editor) environment fader will control only the value byte so you can use any CC as output definition of the remote control fader. The idea is - you can easy record and edit CC automation in Logic which will be transformed into Sysex data etc.

 

A.G

 

http://audiogrocery.com/support/images/sys_mapper.png[/img]

[ruari]

@ Scandor - I've downloaded your Alpha Juno environment in the hope that I could control my Juno 2 with it.

 

If I could get this working then there would be no more need for me to keep searching for a reasonably priced pg300, have you seen how much people are asking for them now?

 

EDIT: It's ok, I've done it - I hadn't turned MIDI Excl to On so it wasn't responding to any incoming messages.

 

Have you got anything else for the Juno stored away anywhere?

[Audiogrocery]

Have you got anything else for the Juno stored away anywhere?

 

Yes, stored in my HDs only

 

I have developed a full version of the "Twins Alpha editor" (the interface looks like the picture above but packed in a Macro - no cables objects etc). I think I have started some very new version some time ago adding a (Header) above the editor, so you can store your new patches directly in the Logic "Twins Alpha Editor". The Header supports internal clipboard for patch management, Program Change etc (have a look at my site RMX PCTRL or Logic SC videos, where I use similar Headers.

I need some time to finish that project...

 

By the way currently I do not plan to release such tools yet, cause have much more work with the sampling projects. I know it can be better than PG300. For example you can get a cheep Behringer BCR2000, and control the Logic Alpha Editor + the Alpha itself, recording CC "dummy" automation on a Logic track and send the CC data as real Sysex back to the Alpha etc.

 

A.G

 

BTW. By the way you have at least two examples - a working prototype scheme of the "Twins" method and a design picture of the whole editor. Take that in your hands and make it by yourself. The Apple Logic trainers must be better in the Environment than Logic amateurs like me.

[Audiogrocery]

It always outputs the following string, regardless of fader value:

F0 41 10 00 59 12 10 00 06 11 08 00 00 00 00 F7

 

Hi Beej,

 

I had some time to experiment offline your scenario.

I re-created a Sys fader and set the Checksum to OFF, Value and Position to "Auto" as I mentioned before (L 8.0.2). Note, I manually set the Sys Bytes message length using the -+ (EOX) buttons to the right. After that I switched the View to "SysEx in Hex Format" and typed the message you provided in your original post. I selected that message and tried the next offline experiment... I created an instrument port set to IAC patched/cabled from the Sys fader, after that I created another Instrument track in the Arrange and recorded the Sysex messages (have a look at the image below). It seems to work this way... Get the experiment Template from the Attachment below and try in real conditions.

Regards,

 

A.G

 

http://audiogrocery.com/support/images/roland_sys_test1.png

roland_sys_a.g_test1.zip

[beej]

It always outputs the following string, regardless of fader value:

F0 41 10 00 59 12 10 00 06 11 08 00 00 00 00 F7

 

I had some time to experiment offline your scenario.

I re-created a Sys fader and set the Checksum to OFF, Value and Position to "Auto" as I mentioned before (L 8.0.2).

 

Well, that's not the issue I was describing.

 

Leaving the redraw issues aside, as already mentioned the sysex "works" if you don't use checksums and manually positioning the val and checksum bytes. Great, but useless for sysex strings that require checksums (quite a lot of them) - and therefore useless in my example scenario.

 

The specific issue I referred to above is that when importing a sysex fader which *correctly checksums* in LP7 (ie, the sysex fader correctly controls my target parameter) into LP8/LP9, the bytes are *not correctly output* (they give the strings I describe, rather than the correct ones). And thus do not work.

 

So the issue was given a real example of one specific case in which the sysex faders are broken.

 

Once again - if you are turning off checksumming etc and saying "it works fine" you are not understanding the issue. Yes - ignoring the redraw issues for now - the sysex fader outputs values as expected *if you don't use those features*. But that can never work for messages that require checksums anyway.

[Audiogrocery]

Once again - if you are turning off checksumming etc and saying "it works fine" you are not understanding the issue.

 

I'm understanding very well. It is quite complicated to work offline and you must understand that I need more info end tests to BE SURE if it is a Sysex Fader (CheckSum) issue or it is a Checksum issue as a whole with L8/9 (here I mean using the second method "Sys Mapper" transformer"- you have not provided any info or experiments yet...

 

As you see I'm doing by best to define the problem and I'm looking for an alternative method how to Fix the issue!

 

I have some results by now:

1. The CheckSum issue is GLOBAL for L8/9 - it is not only for the Sys Fader object in Logic 8/9 which use different (probably wrong) way of Checksum calculation.

I have noted this behavior in both Sys Fader and the Sys Mapper Transformer objects (both objects calculate the Checksum in the same way, which is different in L5) so I guess it is an App global issue. Have a look at my mouse which shows the Checksum parameter in L8 which is (Hex78=120dec, while the same Sys Mapper transformer shows that in L5 as Hex51=81Dec)

 

2. It is clear that L8/9 use different calculation algorithm, that's why I required CheckSum set to OFF, where we know that it works...

If you follow me, my idea is to make a Fix using additional Transformer Scale objects and use a Sys Mapper Transformer with Checksum set to OFF, so I can control the last two bytes following the proper scale calculation I have got from L5.

 

The Experiment results:

The L5 experiment shows:

Value range (Byte 13 = 0-127 Dec)

Sum range (Byte 14 = 81>0>127>82 Dec)

 

The L8/9 experiment shows:

Value range (Byte 13 = 0-127 Dec)

Sum range (Byte 14 = 120>0>127>121 Dec)

 

I have created two paths shown in the image below. The green path is the original method where the Sys Mapper Transformer is set to Roland Checksum, but if you try it I expect it will work as the Sys Fader in L8/9.

 

The second yellow path is the Fix which follows the Sum scale I got from L5.

To try that I routed the Port via IAC and recorded some Sys data on a track. The only issue are the duplicated sys message packs consist of two messages (1st wrong and 2dn OK). I expect that the second will override the 1st - you must try in real conditions.

 

Another question is if the "Scale Law" is same for the all parameters of your machine? Get the Test Template from the attachment!

 

Regards,

 

A.G

 

http://audiogrocery.com/support/images/sys_mapper1.png

roland_sys_a.g_2.zip

[beej]

As you see I'm doing by best to define the problem and I'm looking for an alternative method how to Fix the issue!

 

Ah ok. That didn't come across to me at all in any of your previous posts - from my perspective you just kept ignoring the checksum issue, made no mention of it, and just kept saying "It works when you don't use checksums". (Just like you've kept ignoring my questions about redraw issues as well, I still don't know whether you have these yet.)

 

1. The CheckSum issue is GLOBAL for L8/9 - it is not only for the Sys Fader object in Logic 8/9 which use different (probably wrong) way of Checksum calculation.

 

Oh really? That's interesting...

 

I have noted this behavior in both Sys Fader and the Sys Mapper Transformer objects (both objects calculate the Checksum in the same way, which is different in L5) so I guess it is an App global issue.

 

Ok.

 

Have a look at my mouse which shows the Checksum parameter in L8 which is (Hex78=120dec, while the same Sys Mapper transformer shows that in L5 as Hex51=81Dec)

 

Yep - and we can assume that L5-L7 use the same (working) behaviour, which changed for LP8/9.

 

2. It is clear that L8/9 use different calculation algorithm, that's why I required CheckSum set to OFF, where we know that it works...

 

Ok, it wasn't clear to me what you were doing/saying, but I now understand you better.

 

If you follow me, my idea is to make a Fix using additional Transformer Scale objects and use a Sys Mapper Transformer with Checksum set to OFF, so I can control the last two bytes following the proper scale calculation I have got from L5.

 

Ok - like I say - I'm capable of making workarounds, and as I said I had intended to do that for my application (but if you want to do it for me, that's fine too!

 

This thread for me really wasn't about how to develop workarounds, it was to understand the issues, see if other people could recreate them and to get feedback from others as I've seen very little mention of these issues before now (which rather surprised me!). It seems that even yourself, as quite an extensive environment developer, weren't really aware of these issues until this thread.

 

I do appreciate the help in investigating the issue and you reporting your findings though, that's really helpful. It will help greatly in documenting a bug report. I think I will need to investigate whether it is, for example, *only* the "Roland" checkum format that is broken, or if it is a wider issue affecting other checksum formats....

 

And then look at the next set of issues...

[Audiogrocery]

Just like you've kept ignoring my questions about redraw issues as well, I still don't know whether you have these yet.

 

I'm so sorry to say that the word "redraw" is not in my technical English, so I could not understand the question very well though I guessed what you are talking about. Could you explain in another way ( my English is not native )?

 

It seems that even yourself, as quite an extensive environment developer, weren't really aware of these issues until this thread.

 

Honestly I have not used CheckSum for at least 10 years ( i.e from the times I developed mostly Sysex Editors - there were not such issues). During L8/9 I did not pay an attention about the issue cause I was busy with much other Environment researches.

Thanks for posting the issue! It was interesting for me to do a major research what is causing the problem and I think I got it... It was a pleasure for me to pay an attention on all that.

 

A.G

[beej]

I'm so sorry to say that the word "redraw" is not in my technical English, so I could not understand the question very well though I guessed what you are talking about. Could you explain in another way ( my English is not native )?

 

Ok, no problem. I will describe this in a little while with video to show what I mean... it's an issue with Logic displaying the window which makes it difficult to actually work with the sysex message.

 

Honestly I have not used CheckSum for at least 10 years ( i.e from the times I developed mostly Sysex Editors - there were not such issues). During L8/9 I did not pay an attention about the issue cause I was busy with much other Environment researches.

Thanks for posting the issue! It was interesting for me to do a major research what is causing the problem and I think I got it... It was a pleasure for me to pay an attention on all that.

 

No problem - thanks. Indeed, like I say, quite some things did get broken with sysex faders in LP8, and it seems they tend to be the things that have affected me quite a bit. So it's good that we environment hackers are adding to our understanding of the deeper parts of the environment.

 

So - I will move on from the checksum issue into the next set of issues shortly...

[Audiogrocery]

it's an issue with Logic displaying the window which makes it difficult to actually work with the sysex message.

 

I think this matches what I guessed - in L8/9 the Sys Fader sys message string is shown in a different way rather than say L5/7. I.e the message string bytes in L8/9 are more than the L5/7? If you try to correct the string length via the EOX +- then the length is strangely quantized and quite much shorten so it does not match your L5/7 original length. Do you mean that?

 

Ah, it will be OK if you post some other issues - my ears are getting up like the Donkey ones

 

A.G

[ruari]

Scandor - I have re-worked your Juno template a little, I've changed the layout to make it resemble the pg300 a bit more.

 

I've tested it on my Juno 2 & it's working fine. There is no snapshot recall or anything fancy like that, it's just the control over the synths parameters to save you having to root around through menus & sub menus - just as it would be if you had a real pg300. With your permission I'd like to make it available to others.

[Pietr]

Scandor, is there a way to get this Alpha Juno Environment?

Or maybe Ruari could provide the edited version of it?

I just got an Alpha Juno 2 and would really like a nice environment for it.

[Audiogrocery]

I have not finished the Alpha 2 editor (according to my last design requirements) yet. It must has the functions of this J106 shown in the image below - like hybrid support Sys & CC (so you can draw or record CC to control the Alpha), Preset manager (up to 127 presets, copy, paste, Prg & CC change ctrl etc), Ultimate parameter randomizer, Midi Latch/Hold , Hyper Set for the all Parameters etc.

I contructed this J106 ofline without owning the hardware synth (I used a few demo tester guys for the tests). I hope it will be easier to re-design the Alpha 2 - cause I own one.

Right now I'm very busy with some other projects so I'll give a sign when the Hardware Synth editors are released ( I guess, May-June...).

Regards

 

A.G

[señor bling]

Checksum breakage still going strong six years later in 10.4.4 (sorry for reviving this ancient thread, but it just took me some hours to figure out… damn)