Yahoo Groups archive

Emax

Index last updated: 2026-04-28 23:23 UTC

Thread

Microcontroller

Microcontroller

2009-12-29 by thenewyorkcowboy

I just saw this post on the Yamaha DX group and thought I would put it here for us to comment on as well.  Don't know how it might apply but ideas are welcome.  My initial thought is somehow using this to translate the EMAX source code into something that we could understand and modify, then we could write a new OS that would implement the new features of the extra stuff we put in, or possibly if the stars were aligned we could even replace the dated microprocessor of the EMAX with this one and write brand new code...

Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR

Re: Editor Librarians for TX81Z
Posted by: "Alan Probandt" alan_probandt at yahoo.com   alan_probandt
Mon Dec 28, 2009 7:18 am (PST)


Hello,
  I have noticed the trend towards over-complication that was mentioned in your message and agree.  However instead of resurrecting 1980s 8-bit home computers, I suggest looking into the modern microcontroller scene that is always improving in terms of performance for the price.
  I have been doing MIDI development with the Atmel AVR microcontroller a lot for the past five years or so.  I don't have a lot to show for it, from a professional perspective, but what has been done is in open source and available.  The AVR is almost a 1980s home computer on a inexpensive chip.  There is a 20MHz CPU core running 130+ op-codes, two or three input/output ports, a  serial port UART or two, a cluster of 10 bit analog/digital convertors, several timers, and a Flash ROM space of 4K bytes to 128K bytes.  Lacking is big on-board RAM, video, and sound generators.   Programs are written in free assemblers or C compilers and loaded into the flash ROM.  No need for ultraviolet erasers any more. All programs are stored in the ROM. No program code runs from RAM, which makes AVRs different from home computers.
  Video can be done using attached LCD graphics modules that sell for about $20.  Sound ICs have disappeared probably for good, but MP3 and MIDI are straightforward to implement.  Massive data storage is done on small cheap SD Flash cards at a cost of about $10 per gigabyte.
  AVRs have the same programming 'feel' that the old home computers do, but they are much more widely available.  There isn't any concern that a program written for DOS or Commodore 64 can't be shared because the hardware is unobtainable.
  The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being replaced by the $4 50MHz 32bit ARM-family of microcontrollers, specifically the Cortex M3.  This device is made by many companies, but it is much more difficult to program and is 'overkill' for MIDI applications.
 
  Just a brief update on the alternatives to using unprogrammable desktop PCs for MIDI applications.

Re: [emax] Microcontroller

2009-12-29 by jammie

waste of time it would need to much hacking of motherboards to impliment

if you read the thread on the dx group it is for programming of sysex strings so you change parameters on the fly but it only works on 1 parameter at a time and would need many more controls and code to impliment loads of controls at a time problem with sysex data it can soon overload the midi channel 

he designed it so you colud change a param with out looking at the panel lcd and buttons in real time 
Show quoted textHide quoted text
  ----- Original Message ----- 
  From: thenewyorkcowboy 
  To: emax@yahoogroups.com 
  Sent: Tuesday, December 29, 2009 5:59 PM
  Subject: [emax] Microcontroller


    
  I just saw this post on the Yamaha DX group and thought I would put it here for us to comment on as well. Don't know how it might apply but ideas are welcome. My initial thought is somehow using this to translate the EMAX source code into something that we could understand and modify, then we could write a new OS that would implement the new features of the extra stuff we put in, or possibly if the stars were aligned we could even replace the dated microprocessor of the EMAX with this one and write brand new code...

  Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR

  Re: Editor Librarians for TX81Z
  Posted by: "Alan Probandt" alan_probandt at yahoo.com alan_probandt
  Mon Dec 28, 2009 7:18 am (PST)

  Hello,
  I have noticed the trend towards over-complication that was mentioned in your message and agree. However instead of resurrecting 1980s 8-bit home computers, I suggest looking into the modern microcontroller scene that is always improving in terms of performance for the price.
  I have been doing MIDI development with the Atmel AVR microcontroller a lot for the past five years or so. I don't have a lot to show for it, from a professional perspective, but what has been done is in open source and available. The AVR is almost a 1980s home computer on a inexpensive chip. There is a 20MHz CPU core running 130+ op-codes, two or three input/output ports, a serial port UART or two, a cluster of 10 bit analog/digital convertors, several timers, and a Flash ROM space of 4K bytes to 128K bytes. Lacking is big on-board RAM, video, and sound generators. Programs are written in free assemblers or C compilers and loaded into the flash ROM. No need for ultraviolet erasers any more. All programs are stored in the ROM. No program code runs from RAM, which makes AVRs different from home computers.
  Video can be done using attached LCD graphics modules that sell for about $20. Sound ICs have disappeared probably for good, but MP3 and MIDI are straightforward to implement. Massive data storage is done on small cheap SD Flash cards at a cost of about $10 per gigabyte.
  AVRs have the same programming 'feel' that the old home computers do, but they are much more widely available. There isn't any concern that a program written for DOS or Commodore 64 can't be shared because the hardware is unobtainable.
  The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being replaced by the $4 50MHz 32bit ARM-family of microcontrollers, specifically the Cortex M3. This device is made by many companies, but it is much more difficult to program and is 'overkill' for MIDI applications.

  Just a brief update on the alternatives to using unprogrammable desktop PCs for MIDI applications.



  


------------------------------------------------------------------------------



  No virus found in this incoming message.
  Checked by AVG - www.avg.com 
  Version: 8.5.431 / Virus Database: 270.14.123/2592 - Release Date: 12/29/09 07:47:00


[Non-text portions of this message have been removed]

Re: [emax] Microcontroller

2009-12-29 by Ted Summers

I am just wondering why people keep wanting to change the base underpinnings
of the Emax hardware.
If you aren't happy with what Emax does do, then maybe you need a different
piece of equipment or software to do this "other thing" you are looking to
do?

I certainly understand wanting to maximize the possible options of the Emax.
Heck if I could increase either the HD size / # of banks or Max sample
memory in an Emax 1 that would be great.

But to change out the CPU? What is the purpose of that?
And the Echip is a special purpose IC. You can't just blindly utilize it in
a circuit....

Without the Echip, the Emax is no longer an Emax, it would be something
different.
So I just don't get some of these comments.



On Tue, Dec 29, 2009 at 11:21 AM, jammie <jammie.emma@...>wrote:

>
>
> waste of time it would need to much hacking of motherboards to impliment
>
> if you read the thread on the dx group it is for programming of sysex
> strings so you change parameters on the fly but it only works on 1 parameter
> at a time and would need many more controls and code to impliment loads of
> controls at a time problem with sysex data it can soon overload the midi
> channel
>
> he designed it so you colud change a param with out looking at the panel
> lcd and buttons in real time
> ----- Original Message -----
> From: thenewyorkcowboy
> To: emax@yahoogroups.com <emax%40yahoogroups.com>
> Sent: Tuesday, December 29, 2009 5:59 PM
> Subject: [emax] Microcontroller
>
> I just saw this post on the Yamaha DX group and thought I would put it here
> for us to comment on as well. Don't know how it might apply but ideas are
> welcome. My initial thought is somehow using this to translate the EMAX
> source code into something that we could understand and modify, then we
> could write a new OS that would implement the new features of the extra
> stuff we put in, or possibly if the stars were aligned we could even replace
> the dated microprocessor of the EMAX with this one and write brand new
> code...
>
> Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
>
> Re: Editor Librarians for TX81Z
> Posted by: "Alan Probandt" alan_probandt at yahoo.com alan_probandt
> Mon Dec 28, 2009 7:18 am (PST)
>
> Hello,
> I have noticed the trend towards over-complication that was mentioned in
> your message and agree. However instead of resurrecting 1980s 8-bit home
> computers, I suggest looking into the modern microcontroller scene that is
> always improving in terms of performance for the price.
> I have been doing MIDI development with the Atmel AVR microcontroller a lot
> for the past five years or so. I don't have a lot to show for it, from a
> professional perspective, but what has been done is in open source and
> available. The AVR is almost a 1980s home computer on a inexpensive chip.
> There is a 20MHz CPU core running 130+ op-codes, two or three input/output
> ports, a serial port UART or two, a cluster of 10 bit analog/digital
> convertors, several timers, and a Flash ROM space of 4K bytes to 128K bytes.
> Lacking is big on-board RAM, video, and sound generators. Programs are
> written in free assemblers or C compilers and loaded into the flash ROM. No
> need for ultraviolet erasers any more. All programs are stored in the ROM.
> No program code runs from RAM, which makes AVRs different from home
> computers.
> Video can be done using attached LCD graphics modules that sell for about
> $20. Sound ICs have disappeared probably for good, but MP3 and MIDI are
> straightforward to implement. Massive data storage is done on small cheap SD
> Flash cards at a cost of about $10 per gigabyte.
> AVRs have the same programming 'feel' that the old home computers do, but
> they are much more widely available. There isn't any concern that a program
> written for DOS or Commodore 64 can't be shared because the hardware is
> unobtainable.
> The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being replaced by the
> $4 50MHz 32bit ARM-family of microcontrollers, specifically the Cortex M3.
> This device is made by many companies, but it is much more difficult to
> program and is 'overkill' for MIDI applications.
>
> Just a brief update on the alternatives to using unprogrammable desktop PCs
> for MIDI applications.
>
> ----------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.431 / Virus Database: 270.14.123/2592 - Release Date: 12/29/09
> 07:47:00
>
> [Non-text portions of this message have been removed]
>
>  
>


[Non-text portions of this message have been removed]

Re: [emax] Microcontroller

2009-12-29 by Brooks Mosher

well what if you like most of what the Emax can do but feel it's limited in
a small way?  for example, personally, i love the sound, and i can deal with
most of it's limitations, but one thing that i do wish was improved upon is
the MIDI timing.  trying to use it as a sampler for drums w/ an external
sequencer (as this is how i produce music) is a near impossible thing when
you start using more than 3 drum sounds, especially if you are doing more
than a simple 1-2 1-2 beat - i end up having to solo each drum part's
pattern and then multi track all of them which is something i prefer to
avoid since i lose that "live" feel i get otherwise.

so wouldn't a faster cpu fix the MIDI timing problem?  but then again, even
if it could in theory, wouldn't it be a monumental task and not really worth
it at the end of the day?  and i'm sure many people would just tell me to
get an Akai or use software programs and stop my bitching...  ;)

but yeah if the MIDI timing wasn't an issue the Emax would be a perfect
machine for me.



On Tue, Dec 29, 2009 at 3:38 PM, Ted Summers <djtbs1@...> wrote:

> I am just wondering why people keep wanting to change the base
> underpinnings
> of the Emax hardware.
> If you aren't happy with what Emax does do, then maybe you need a different
> piece of equipment or software to do this "other thing" you are looking to
> do?
>
> I certainly understand wanting to maximize the possible options of the
> Emax.
> Heck if I could increase either the HD size / # of banks or Max sample
> memory in an Emax 1 that would be great.
>
> But to change out the CPU? What is the purpose of that?
> And the Echip is a special purpose IC. You can't just blindly utilize it in
> a circuit....
>
> Without the Echip, the Emax is no longer an Emax, it would be something
> different.
> So I just don't get some of these comments.
>
>
>
> On Tue, Dec 29, 2009 at 11:21 AM, jammie <jammie.emma@...
> >wrote:
>
> >
> >
> > waste of time it would need to much hacking of motherboards to impliment
> >
> > if you read the thread on the dx group it is for programming of sysex
> > strings so you change parameters on the fly but it only works on 1
> parameter
> > at a time and would need many more controls and code to impliment loads
> of
> > controls at a time problem with sysex data it can soon overload the midi
> > channel
> >
> > he designed it so you colud change a param with out looking at the panel
> > lcd and buttons in real time
> > ----- Original Message -----
> > From: thenewyorkcowboy
> > To: emax@yahoogroups.com <emax%40yahoogroups.com>
> > Sent: Tuesday, December 29, 2009 5:59 PM
> > Subject: [emax] Microcontroller
> >
> > I just saw this post on the Yamaha DX group and thought I would put it
> here
> > for us to comment on as well. Don't know how it might apply but ideas are
> > welcome. My initial thought is somehow using this to translate the EMAX
> > source code into something that we could understand and modify, then we
> > could write a new OS that would implement the new features of the extra
> > stuff we put in, or possibly if the stars were aligned we could even
> replace
> > the dated microprocessor of the EMAX with this one and write brand new
> > code...
> >
> > Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
> >
> > Re: Editor Librarians for TX81Z
> > Posted by: "Alan Probandt" alan_probandt at yahoo.com alan_probandt
> > Mon Dec 28, 2009 7:18 am (PST)
> >
> > Hello,
> > I have noticed the trend towards over-complication that was mentioned in
> > your message and agree. However instead of resurrecting 1980s 8-bit home
> > computers, I suggest looking into the modern microcontroller scene that
> is
> > always improving in terms of performance for the price.
> > I have been doing MIDI development with the Atmel AVR microcontroller a
> lot
> > for the past five years or so. I don't have a lot to show for it, from a
> > professional perspective, but what has been done is in open source and
> > available. The AVR is almost a 1980s home computer on a inexpensive chip.
> > There is a 20MHz CPU core running 130+ op-codes, two or three
> input/output
> > ports, a serial port UART or two, a cluster of 10 bit analog/digital
> > convertors, several timers, and a Flash ROM space of 4K bytes to 128K
> bytes.
> > Lacking is big on-board RAM, video, and sound generators. Programs are
> > written in free assemblers or C compilers and loaded into the flash ROM.
> No
> > need for ultraviolet erasers any more. All programs are stored in the
> ROM.
> > No program code runs from RAM, which makes AVRs different from home
> > computers.
> > Video can be done using attached LCD graphics modules that sell for about
> > $20. Sound ICs have disappeared probably for good, but MP3 and MIDI are
> > straightforward to implement. Massive data storage is done on small cheap
> SD
> > Flash cards at a cost of about $10 per gigabyte.
> > AVRs have the same programming 'feel' that the old home computers do, but
> > they are much more widely available. There isn't any concern that a
> program
> > written for DOS or Commodore 64 can't be shared because the hardware is
> > unobtainable.
> > The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being replaced by
> the
> > $4 50MHz 32bit ARM-family of microcontrollers, specifically the Cortex
> M3.
> > This device is made by many companies, but it is much more difficult to
> > program and is 'overkill' for MIDI applications.
> >
> > Just a brief update on the alternatives to using unprogrammable desktop
> PCs
> > for MIDI applications.
> >
> > ----------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.431 / Virus Database: 270.14.123/2592 - Release Date:
> 12/29/09
> > 07:47:00
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Emax and Emax II User's Group Website
>
> http://www.silveriafamily.comYahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Re: [emax] Microcontroller

2009-12-29 by Ted Summers

Well, your assertion is assuming the MIDI timing is a CPU issue and not one
of a slightly off MIDI clock, or issue with the MIDI clock circuit design.

Maybe that specific item could be looked into- does everyone have that same
issue with the MIDI- or is something wrong with the MIDI circuit in  Brooks
Emax?

Any comments?

Regards,
Ted




On Tue, Dec 29, 2009 at 1:55 PM, Brooks Mosher <brooksmosher@...>wrote:

>
>
> well what if you like most of what the Emax can do but feel it's limited in
> a small way? for example, personally, i love the sound, and i can deal with
> most of it's limitations, but one thing that i do wish was improved upon is
> the MIDI timing. trying to use it as a sampler for drums w/ an external
> sequencer (as this is how i produce music) is a near impossible thing when
> you start using more than 3 drum sounds, especially if you are doing more
> than a simple 1-2 1-2 beat - i end up having to solo each drum part's
> pattern and then multi track all of them which is something i prefer to
> avoid since i lose that "live" feel i get otherwise.
>
> so wouldn't a faster cpu fix the MIDI timing problem? but then again, even
> if it could in theory, wouldn't it be a monumental task and not really
> worth
> it at the end of the day? and i'm sure many people would just tell me to
> get an Akai or use software programs and stop my bitching... ;)
>
> but yeah if the MIDI timing wasn't an issue the Emax would be a perfect
> machine for me.
>
>
> On Tue, Dec 29, 2009 at 3:38 PM, Ted Summers <djtbs1@...<djtbs1%40gmail.com>>
> wrote:
>
> > I am just wondering why people keep wanting to change the base
> > underpinnings
> > of the Emax hardware.
> > If you aren't happy with what Emax does do, then maybe you need a
> different
> > piece of equipment or software to do this "other thing" you are looking
> to
> > do?
> >
> > I certainly understand wanting to maximize the possible options of the
> > Emax.
> > Heck if I could increase either the HD size / # of banks or Max sample
> > memory in an Emax 1 that would be great.
> >
> > But to change out the CPU? What is the purpose of that?
> > And the Echip is a special purpose IC. You can't just blindly utilize it
> in
> > a circuit....
> >
> > Without the Echip, the Emax is no longer an Emax, it would be something
> > different.
> > So I just don't get some of these comments.
> >
> >
> >
> > On Tue, Dec 29, 2009 at 11:21 AM, jammie <jammie.emma@...<jammie.emma%40blueyonder.co.uk>
> > >wrote:
> >
> > >
> > >
> > > waste of time it would need to much hacking of motherboards to
> impliment
> > >
> > > if you read the thread on the dx group it is for programming of sysex
> > > strings so you change parameters on the fly but it only works on 1
> > parameter
> > > at a time and would need many more controls and code to impliment loads
> > of
> > > controls at a time problem with sysex data it can soon overload the
> midi
> > > channel
> > >
> > > he designed it so you colud change a param with out looking at the
> panel
> > > lcd and buttons in real time
> > > ----- Original Message -----
> > > From: thenewyorkcowboy
>  > > To: emax@yahoogroups.com <emax%40yahoogroups.com> <emax%
> 40yahoogroups.com>
> > > Sent: Tuesday, December 29, 2009 5:59 PM
> > > Subject: [emax] Microcontroller
> > >
> > > I just saw this post on the Yamaha DX group and thought I would put it
> > here
> > > for us to comment on as well. Don't know how it might apply but ideas
> are
> > > welcome. My initial thought is somehow using this to translate the EMAX
> > > source code into something that we could understand and modify, then we
> > > could write a new OS that would implement the new features of the extra
> > > stuff we put in, or possibly if the stars were aligned we could even
> > replace
> > > the dated microprocessor of the EMAX with this one and write brand new
> > > code...
> > >
> > > Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
> > >
> > > Re: Editor Librarians for TX81Z
> > > Posted by: "Alan Probandt" alan_probandt at yahoo.com alan_probandt
> > > Mon Dec 28, 2009 7:18 am (PST)
> > >
> > > Hello,
> > > I have noticed the trend towards over-complication that was mentioned
> in
> > > your message and agree. However instead of resurrecting 1980s 8-bit
> home
> > > computers, I suggest looking into the modern microcontroller scene that
> > is
> > > always improving in terms of performance for the price.
> > > I have been doing MIDI development with the Atmel AVR microcontroller a
> > lot
> > > for the past five years or so. I don't have a lot to show for it, from
> a
> > > professional perspective, but what has been done is in open source and
> > > available. The AVR is almost a 1980s home computer on a inexpensive
> chip.
> > > There is a 20MHz CPU core running 130+ op-codes, two or three
> > input/output
> > > ports, a serial port UART or two, a cluster of 10 bit analog/digital
> > > convertors, several timers, and a Flash ROM space of 4K bytes to 128K
> > bytes.
> > > Lacking is big on-board RAM, video, and sound generators. Programs are
> > > written in free assemblers or C compilers and loaded into the flash
> ROM.
> > No
> > > need for ultraviolet erasers any more. All programs are stored in the
> > ROM.
> > > No program code runs from RAM, which makes AVRs different from home
> > > computers.
> > > Video can be done using attached LCD graphics modules that sell for
> about
> > > $20. Sound ICs have disappeared probably for good, but MP3 and MIDI are
> > > straightforward to implement. Massive data storage is done on small
> cheap
> > SD
> > > Flash cards at a cost of about $10 per gigabyte.
> > > AVRs have the same programming 'feel' that the old home computers do,
> but
> > > they are much more widely available. There isn't any concern that a
> > program
> > > written for DOS or Commodore 64 can't be shared because the hardware is
> > > unobtainable.
> > > The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being replaced by
> > the
> > > $4 50MHz 32bit ARM-family of microcontrollers, specifically the Cortex
> > M3.
> > > This device is made by many companies, but it is much more difficult to
> > > program and is 'overkill' for MIDI applications.
> > >
> > > Just a brief update on the alternatives to using unprogrammable desktop
> > PCs
> > > for MIDI applications.
> > >
> > > ----------------------------------------------------------
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG - www.avg.com
> > > Version: 8.5.431 / Virus Database: 270.14.123/2592 - Release Date:
> > 12/29/09
> > > 07:47:00
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
>
> >
> > Emax and Emax II User's Group Website
> >
> > http://www.silveriafamily.comYahoo <http://www.silveriafamily.comyahoo/>!
> Groups Links
>
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>  
>


[Non-text portions of this message have been removed]

Re: [emax] Microcontroller

2009-12-30 by Brooks Mosher

yeah i have no idea what could cause it...  i noticed it on a Baldwin i had
years ago while running a drum pattern from my ext sequencer but also had
sequences running to other gear on separate MIDI channels, including another
drum pattern to a Jomox Airbase99, and only noticed the sloppiness with the
Baldwin.  i did a little reading and the Emulator Archive page confirmed
this for Emax and mentioned the main processor being somewhat overloaded.

http://www.emulatorarchive.com/Archives/Samplers/EmaxOverview/EmaxTech/emaxtech.html

i've also experienced the same issue with my Emax rack i now use.  like i
said, it's not an issue for simple drum patterns but when you start doing a
16th note pattern on a hi hat for example, it's very easy to hear.

anyways there's always a work around in the studio and to me, owning an Emax
quite versatile in terms of offering true 8/12 bit samples of those vintage
drum machines like the Linn Drum or the DMX so i'm not complaining.  :)



On Tue, Dec 29, 2009 at 5:51 PM, Ted Summers <djtbs1@...> wrote:

> Well, your assertion is assuming the MIDI timing is a CPU issue and not one
> of a slightly off MIDI clock, or issue with the MIDI clock circuit design.
>
> Maybe that specific item could be looked into- does everyone have that same
> issue with the MIDI- or is something wrong with the MIDI circuit in  Brooks
> Emax?
>
> Any comments?
>
> Regards,
> Ted
>
>
>
>
> On Tue, Dec 29, 2009 at 1:55 PM, Brooks Mosher <brooksmosher@...
> >wrote:
>
> >
> >
> > well what if you like most of what the Emax can do but feel it's limited
> in
> > a small way? for example, personally, i love the sound, and i can deal
> with
> > most of it's limitations, but one thing that i do wish was improved upon
> is
> > the MIDI timing. trying to use it as a sampler for drums w/ an external
> > sequencer (as this is how i produce music) is a near impossible thing
> when
> > you start using more than 3 drum sounds, especially if you are doing more
> > than a simple 1-2 1-2 beat - i end up having to solo each drum part's
> > pattern and then multi track all of them which is something i prefer to
> > avoid since i lose that "live" feel i get otherwise.
> >
> > so wouldn't a faster cpu fix the MIDI timing problem? but then again,
> even
> > if it could in theory, wouldn't it be a monumental task and not really
> > worth
> > it at the end of the day? and i'm sure many people would just tell me to
> > get an Akai or use software programs and stop my bitching... ;)
> >
> > but yeah if the MIDI timing wasn't an issue the Emax would be a perfect
> > machine for me.
> >
> >
> > On Tue, Dec 29, 2009 at 3:38 PM, Ted Summers <djtbs1@...<djtbs1%
> 40gmail.com>>
> > wrote:
> >
> > > I am just wondering why people keep wanting to change the base
> > > underpinnings
> > > of the Emax hardware.
> > > If you aren't happy with what Emax does do, then maybe you need a
> > different
> > > piece of equipment or software to do this "other thing" you are looking
> > to
> > > do?
> > >
> > > I certainly understand wanting to maximize the possible options of the
> > > Emax.
> > > Heck if I could increase either the HD size / # of banks or Max sample
> > > memory in an Emax 1 that would be great.
> > >
> > > But to change out the CPU? What is the purpose of that?
> > > And the Echip is a special purpose IC. You can't just blindly utilize
> it
> > in
> > > a circuit....
> > >
> > > Without the Echip, the Emax is no longer an Emax, it would be something
> > > different.
> > > So I just don't get some of these comments.
> > >
> > >
> > >
> > > On Tue, Dec 29, 2009 at 11:21 AM, jammie <jammie.emma@...
> <jammie.emma%40blueyonder.co.uk>
> > > >wrote:
> > >
> > > >
> > > >
> > > > waste of time it would need to much hacking of motherboards to
> > impliment
> > > >
> > > > if you read the thread on the dx group it is for programming of sysex
> > > > strings so you change parameters on the fly but it only works on 1
> > > parameter
> > > > at a time and would need many more controls and code to impliment
> loads
> > > of
> > > > controls at a time problem with sysex data it can soon overload the
> > midi
> > > > channel
> > > >
> > > > he designed it so you colud change a param with out looking at the
> > panel
> > > > lcd and buttons in real time
> > > > ----- Original Message -----
> > > > From: thenewyorkcowboy
> >  > > To: emax@yahoogroups.com <emax%40yahoogroups.com> <emax%
> > 40yahoogroups.com>
> > > > Sent: Tuesday, December 29, 2009 5:59 PM
> > > > Subject: [emax] Microcontroller
> > > >
> > > > I just saw this post on the Yamaha DX group and thought I would put
> it
> > > here
> > > > for us to comment on as well. Don't know how it might apply but ideas
> > are
> > > > welcome. My initial thought is somehow using this to translate the
> EMAX
> > > > source code into something that we could understand and modify, then
> we
> > > > could write a new OS that would implement the new features of the
> extra
> > > > stuff we put in, or possibly if the stars were aligned we could even
> > > replace
> > > > the dated microprocessor of the EMAX with this one and write brand
> new
> > > > code...
> > > >
> > > > Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
> > > >
> > > > Re: Editor Librarians for TX81Z
> > > > Posted by: "Alan Probandt" alan_probandt at yahoo.com alan_probandt
> > > > Mon Dec 28, 2009 7:18 am (PST)
> > > >
> > > > Hello,
> > > > I have noticed the trend towards over-complication that was mentioned
> > in
> > > > your message and agree. However instead of resurrecting 1980s 8-bit
> > home
> > > > computers, I suggest looking into the modern microcontroller scene
> that
> > > is
> > > > always improving in terms of performance for the price.
> > > > I have been doing MIDI development with the Atmel AVR microcontroller
> a
> > > lot
> > > > for the past five years or so. I don't have a lot to show for it,
> from
> > a
> > > > professional perspective, but what has been done is in open source
> and
> > > > available. The AVR is almost a 1980s home computer on a inexpensive
> > chip.
> > > > There is a 20MHz CPU core running 130+ op-codes, two or three
> > > input/output
> > > > ports, a serial port UART or two, a cluster of 10 bit analog/digital
> > > > convertors, several timers, and a Flash ROM space of 4K bytes to 128K
> > > bytes.
> > > > Lacking is big on-board RAM, video, and sound generators. Programs
> are
> > > > written in free assemblers or C compilers and loaded into the flash
> > ROM.
> > > No
> > > > need for ultraviolet erasers any more. All programs are stored in the
> > > ROM.
> > > > No program code runs from RAM, which makes AVRs different from home
> > > > computers.
> > > > Video can be done using attached LCD graphics modules that sell for
> > about
> > > > $20. Sound ICs have disappeared probably for good, but MP3 and MIDI
> are
> > > > straightforward to implement. Massive data storage is done on small
> > cheap
> > > SD
> > > > Flash cards at a cost of about $10 per gigabyte.
> > > > AVRs have the same programming 'feel' that the old home computers do,
> > but
> > > > they are much more widely available. There isn't any concern that a
> > > program
> > > > written for DOS or Commodore 64 can't be shared because the hardware
> is
> > > > unobtainable.
> > > > The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being replaced
> by
> > > the
> > > > $4 50MHz 32bit ARM-family of microcontrollers, specifically the
> Cortex
> > > M3.
> > > > This device is made by many companies, but it is much more difficult
> to
> > > > program and is 'overkill' for MIDI applications.
> > > >
> > > > Just a brief update on the alternatives to using unprogrammable
> desktop
> > > PCs
> > > > for MIDI applications.
> > > >
> > > > ----------------------------------------------------------
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG - www.avg.com
> > > > Version: 8.5.431 / Virus Database: 270.14.123/2592 - Release Date:
> > > 12/29/09
> > > > 07:47:00
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > >
> > > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > ------------------------------------
> >
> > >
> > > Emax and Emax II User's Group Website
> > >
> > > http://www.silveriafamily.comYahoo <
> http://www.silveriafamily.comyahoo/>!
> > Groups Links
> >
> > >
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Emax and Emax II User's Group Website
>
> http://www.silveriafamily.comYahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Re: [emax] Microcontroller

2009-12-30 by tu@...

The fundamental issue is we do not have the source code, let alone the documentation and development environment. We 
have the binaries for the boot ROMs and disk OS but that is not the same as the source code. Its a long a difficult road to 
disassemble and understand binary files and it is not made any easier by the Emax using a fairly obscure and complicated 
main CPU. So what you suggest is unlikely to happen any time soon.

/Tristan
Show quoted textHide quoted text
On Wed, Dec 30th, 2009 at 4:59 AM, thenewyorkcowboy <thenewyorkcowboy@...> wrote:

> I just saw this post on the Yamaha DX group and thought I would put
> it here for us to comment on as well.  Don't know how it might apply
> but ideas are welcome.  My initial thought is somehow using this to
> translate the EMAX source code into something that we could
> understand and modify, then we could write a new OS that would
> implement the new features of the extra stuff we put in, or possibly
> if the stars were aligned we could even replace the dated
> microprocessor of the EMAX with this one and write brand new code...
> 
> Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
> 
> Re: Editor Librarians for TX81Z
> Posted by: "Alan Probandt" alan_probandt at yahoo.com  
> alan_probandt
> Mon Dec 28, 2009 7:18 am (PST)
> 
> 
> Hello,
>   I have noticed the trend towards over-complication that was
> mentioned in your message and agree.  However instead of resurrecting
> 1980s 8-bit home computers, I suggest looking into the modern
> microcontroller scene that is always improving in terms of
> performance for the price.
>   I have been doing MIDI development with the Atmel AVR
> microcontroller a lot for the past five years or so.  I don't have a
> lot to show for it, from a professional perspective, but what has
> been done is in open source and available.  The AVR is almost a 1980s
> home computer on a inexpensive chip.  There is a 20MHz CPU core
> running 130+ op-codes, two or three input/output ports, a  serial
> port UART or two, a cluster of 10 bit analog/digital convertors,
> several timers, and a Flash ROM space of 4K bytes to 128K bytes. 
> Lacking is big on-board RAM, video, and sound generators.   Programs
> are written in free assemblers or C compilers and loaded into the
> flash ROM.  No need for ultraviolet erasers any more. All programs
> are stored in the ROM. No program code runs from RAM, which makes
> AVRs different from home computers.
>   Video can be done using attached LCD graphics modules that sell for
> about $20.  Sound ICs have disappeared probably for good, but MP3 and
> MIDI are straightforward to implement.  Massive data storage is done
> on small cheap SD Flash cards at a cost of about $10 per gigabyte.
>   AVRs have the same programming 'feel' that the old home computers
> do, but they are much more widely available.  There isn't any concern
> that a program written for DOS or Commodore 64 can't be shared
> because the hardware is unobtainable.
>   The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being
> replaced by the $4 50MHz 32bit ARM-family of microcontrollers,
> specifically the Cortex M3.  This device is made by many companies,
> but it is much more difficult to program and is 'overkill' for MIDI
> applications.
>  
>   Just a brief update on the alternatives to using unprogrammable
> desktop PCs for MIDI applications.
> 
>

Re: [emax] Microcontroller

2009-12-30 by Ted Summers

My CPU is designated as a 10Mhz.....it might me possible to change the  
quartz crystal / clocking circuit to use 10Mhz instead of 8Mhz- a 25%  
increase....

Now that may be more do-able....

Regards,
Ted




On Dec 29, 2009, at 4:22 PM, Brooks Mosher wrote:

http://www.emulatorarchive.com/Archives/Samplers/EmaxOverview/EmaxTech/emaxtech.html



[Non-text portions of this message have been removed]

Re: [emax] Microcontroller

2009-12-30 by Ted Summers

A little more reading in the Emax Service Manual yields the fact that  
the E-Chip is synchronized with the CPU and expects certain timing  
intervals.
You can't clock up the CPU without affecting the Echip operation.

So you could conceivably clock up the CPU, but then it would have to  
wait for the Echip.

So I don't think changing the clock is viable.

Regards,
Ted



On Dec 29, 2009, at 4:22 PM, Brooks Mosher wrote:

yeah i have no idea what could cause it... i noticed it on a Baldwin i  
had
years ago while running a drum pattern from my ext sequencer but also  
had
sequences running to other gear on separate MIDI channels, including  
another
drum pattern to a Jomox Airbase99, and only noticed the sloppiness  
with the
Baldwin. i did a little reading and the Emulator Archive page confirmed
this for Emax and mentioned the main processor being somewhat  
overloaded.

http://www.emulatorarchive.com/Archives/Samplers/EmaxOverview/EmaxTech/emaxtech.html

i've also experienced the same issue with my Emax rack i now use. like i
said, it's not an issue for simple drum patterns but when you start  
doing a
16th note pattern on a hi hat for example, it's very easy to hear.

anyways there's always a work around in the studio and to me, owning  
an Emax
quite versatile in terms of offering true 8/12 bit samples of those  
vintage
drum machines like the Linn Drum or the DMX so i'm not complaining. :)

On Tue, Dec 29, 2009 at 5:51 PM, Ted Summers <djtbs1@...> wrote:

 > Well, your assertion is assuming the MIDI timing is a CPU issue and  
not one
 > of a slightly off MIDI clock, or issue with the MIDI clock circuit  
design.
 >
 > Maybe that specific item could be looked into- does everyone have  
that same
 > issue with the MIDI- or is something wrong with the MIDI circuit in  
Brooks
 > Emax?
 >
 > Any comments?
 >
 > Regards,
 > Ted
 >
 >
 >
 >
 > On Tue, Dec 29, 2009 at 1:55 PM, Brooks Mosher  
<brooksmosher@gmail.com
 > >wrote:
 >
 > >
 > >
 > > well what if you like most of what the Emax can do but feel it's  
limited
 > in
 > > a small way? for example, personally, i love the sound, and i can  
deal
 > with
 > > most of it's limitations, but one thing that i do wish was  
improved upon
 > is
 > > the MIDI timing. trying to use it as a sampler for drums w/ an  
external
 > > sequencer (as this is how i produce music) is a near impossible  
thing
 > when
 > > you start using more than 3 drum sounds, especially if you are  
doing more
 > > than a simple 1-2 1-2 beat - i end up having to solo each drum  
part's
 > > pattern and then multi track all of them which is something i  
prefer to
 > > avoid since i lose that "live" feel i get otherwise.
 > >
 > > so wouldn't a faster cpu fix the MIDI timing problem? but then  
again,
 > even
 > > if it could in theory, wouldn't it be a monumental task and not  
really
 > > worth
 > > it at the end of the day? and i'm sure many people would just  
tell me to
 > > get an Akai or use software programs and stop my bitching... ;)
 > >
 > > but yeah if the MIDI timing wasn't an issue the Emax would be a  
perfect
 > > machine for me.
 > >
 > >
 > > On Tue, Dec 29, 2009 at 3:38 PM, Ted Summers  
<djtbs1@...<djtbs1%
 > 40gmail.com>>
 > > wrote:
 > >
 > > > I am just wondering why people keep wanting to change the base
 > > > underpinnings
 > > > of the Emax hardware.
 > > > If you aren't happy with what Emax does do, then maybe you need a
 > > different
 > > > piece of equipment or software to do this "other thing" you are  
looking
 > > to
 > > > do?
 > > >
 > > > I certainly understand wanting to maximize the possible options  
of the
 > > > Emax.
 > > > Heck if I could increase either the HD size / # of banks or Max  
sample
 > > > memory in an Emax 1 that would be great.
 > > >
 > > > But to change out the CPU? What is the purpose of that?
 > > > And the Echip is a special purpose IC. You can't just blindly  
utilize
 > it
 > > in
 > > > a circuit....
 > > >
 > > > Without the Echip, the Emax is no longer an Emax, it would be  
something
 > > > different.
 > > > So I just don't get some of these comments.
 > > >
 > > >
 > > >
 > > > On Tue, Dec 29, 2009 at 11:21 AM, jammie <jammie.emma@...
 > <jammie.emma%40blueyonder.co.uk>
 > > > >wrote:
 > > >
 > > > >
 > > > >
 > > > > waste of time it would need to much hacking of motherboards to
 > > impliment
 > > > >
 > > > > if you read the thread on the dx group it is for programming  
of sysex
 > > > > strings so you change parameters on the fly but it only works  
on 1
 > > > parameter
 > > > > at a time and would need many more controls and code to  
impliment
 > loads
 > > > of
 > > > > controls at a time problem with sysex data it can soon  
overload the
 > > midi
 > > > > channel
 > > > >
 > > > > he designed it so you colud change a param with out looking  
at the
 > > panel
 > > > > lcd and buttons in real time
 > > > > ----- Original Message -----
 > > > > From: thenewyorkcowboy
 > > > > To: emax@yahoogroups.com <emax%40yahoogroups.com> <emax%
 > > 40yahoogroups.com>
 > > > > Sent: Tuesday, December 29, 2009 5:59 PM
 > > > > Subject: [emax] Microcontroller
 > > > >
 > > > > I just saw this post on the Yamaha DX group and thought I  
would put
 > it
 > > > here
 > > > > for us to comment on as well. Don't know how it might apply  
but ideas
 > > are
 > > > > welcome. My initial thought is somehow using this to  
translate the
 > EMAX
 > > > > source code into something that we could understand and  
modify, then
 > we
 > > > > could write a new OS that would implement the new features of  
the
 > extra
 > > > > stuff we put in, or possibly if the stars were aligned we  
could even
 > > > replace
 > > > > the dated microprocessor of the EMAX with this one and write  
brand
 > new
 > > > > code...
 > > > >
 > > > > Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
 > > > >
 > > > > Re: Editor Librarians for TX81Z
 > > > > Posted by: "Alan Probandt" alan_probandt at yahoo.com  
alan_probandt
 > > > > Mon Dec 28, 2009 7:18 am (PST)
 > > > >
 > > > > Hello,
 > > > > I have noticed the trend towards over-complication that was  
mentioned
 > > in
 > > > > your message and agree. However instead of resurrecting 1980s  
8-bit
 > > home
 > > > > computers, I suggest looking into the modern microcontroller  
scene
 > that
 > > > is
 > > > > always improving in terms of performance for the price.
 > > > > I have been doing MIDI development with the Atmel AVR  
microcontroller
 > a
 > > > lot
 > > > > for the past five years or so. I don't have a lot to show for  
it,
 > from
 > > a
 > > > > professional perspective, but what has been done is in open  
source
 > and
 > > > > available. The AVR is almost a 1980s home computer on a  
inexpensive
 > > chip.
 > > > > There is a 20MHz CPU core running 130+ op-codes, two or three
 > > > input/output
 > > > > ports, a serial port UART or two, a cluster of 10 bit analog/ 
digital
 > > > > convertors, several timers, and a Flash ROM space of 4K bytes  
to 128K
 > > > bytes.
 > > > > Lacking is big on-board RAM, video, and sound generators.  
Programs
 > are
 > > > > written in free assemblers or C compilers and loaded into the  
flash
 > > ROM.
 > > > No
 > > > > need for ultraviolet erasers any more. All programs are  
stored in the
 > > > ROM.
 > > > > No program code runs from RAM, which makes AVRs different  
from home
 > > > > computers.
 > > > > Video can be done using attached LCD graphics modules that  
sell for
 > > about
 > > > > $20. Sound ICs have disappeared probably for good, but MP3  
and MIDI
 > are
 > > > > straightforward to implement. Massive data storage is done on  
small
 > > cheap
 > > > SD
 > > > > Flash cards at a cost of about $10 per gigabyte.
 > > > > AVRs have the same programming 'feel' that the old home  
computers do,
 > > but
 > > > > they are much more widely available. There isn't any concern  
that a
 > > > program
 > > > > written for DOS or Commodore 64 can't be shared because the  
hardware
 > is
 > > > > unobtainable.
 > > > > The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being  
replaced
 > by
 > > > the
 > > > > $4 50MHz 32bit ARM-family of microcontrollers, specifically the
 > Cortex
 > > > M3.
 > > > > This device is made by many companies, but it is much more  
difficult
 > to
 > > > > program and is 'overkill' for MIDI applications.
 > > > >
 > > > > Just a brief update on the alternatives to using unprogrammable
 > desktop
 > > > PCs
 > > > > for MIDI applications.
 > > > >
 > > > > ----------------------------------------------------------
 > > > >
 > > > > No virus found in this incoming message.
 > > > > Checked by AVG - www.avg.com
 > > > > Version: 8.5.431 / Virus Database: 270.14.123/2592 - Release  
Date:
 > > > 12/29/09
 > > > > 07:47:00
 > > > >
 > > > > [Non-text portions of this message have been removed]
 > > > >
 > > > >
 > > > >
 > > >
 > > >
 > > > [Non-text portions of this message have been removed]
 > > >
 > > >
 > > >
 > > > ------------------------------------
 > >
 > > >
 > > > Emax and Emax II User's Group Website
 > > >
 > > > http://www.silveriafamily.comYahoo <
 > http://www.silveriafamily.comyahoo/>!
 > > Groups Links
 > >
 > > >
 > > >
 > > >
 > > >
 > >
 > > [Non-text portions of this message have been removed]
 > >
 > >
 > >
 >
 >
 > [Non-text portions of this message have been removed]
 >
 >
 >
 > ------------------------------------
 >
 > Emax and Emax II User's Group Website
 >
 > http://www.silveriafamily.comYahoo! Groups Links
 >
 >
 >
 >

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

Re: Microcontroller

2009-12-30 by emax_dx5

I have had midi issues when trying to play (and then record) a 1/16 sequence into my emax at 130 bpm aprox. Some Notes were hidden and others were like jumping out of synch. I finally had to put my pro tools system in "manual tempo playback", then played the sequence at 70-80 bpm and so I could record it (then had to do a 80 to 130 time stretch to the file, et voila).



--- In emax@yahoogroups.com, Ted Summers <djtbs1@...> wrote:
Show quoted textHide quoted text
>
> Well, your assertion is assuming the MIDI timing is a CPU issue and not one
> of a slightly off MIDI clock, or issue with the MIDI clock circuit design.
> 
> Maybe that specific item could be looked into- does everyone have that same
> issue with the MIDI- or is something wrong with the MIDI circuit in  Brooks
> Emax?
> 
> Any comments?
> 
> Regards,
> Ted
> 
>

Re: [emax] Re: Microcontroller

2009-12-30 by Ted Summers

I guess one question might be, has anyone tried this using a master clock
for sync between say the ProTools (example) and the Emax?
It looks like the clock comes in over the DB-9 not the Midi cable on the
Emax. Just a thought.
Wondering if there was a master sync outside of Emax if that overrides the
problem?

regards,
Ted

On Wed, Dec 30, 2009 at 5:33 AM, emax_dx5 <cadena100rb@...> wrote:

>
>
>
> I have had midi issues when trying to play (and then record) a 1/16
> sequence into my emax at 130 bpm aprox. Some Notes were hidden and others
> were like jumping out of synch. I finally had to put my pro tools system in
> "manual tempo playback", then played the sequence at 70-80 bpm and so I
> could record it (then had to do a 80 to 130 time stretch to the file, et
> voila).
>
>
> --- In emax@yahoogroups.com <emax%40yahoogroups.com>, Ted Summers <djtbs1@...>
> wrote:
> >
> > Well, your assertion is assuming the MIDI timing is a CPU issue and not
> one
> > of a slightly off MIDI clock, or issue with the MIDI clock circuit
> design.
> >
> > Maybe that specific item could be looked into- does everyone have that
> same
> > issue with the MIDI- or is something wrong with the MIDI circuit in
> Brooks
> > Emax?
> >
> > Any comments?
> >
> > Regards,
> > Ted
> >
> >
>
>  
>


[Non-text portions of this message have been removed]

Re: [emax] Microcontroller

2009-12-30 by Michael Wisbech

don't know a thing But maybe it is using the last 2mhz  to different 
prossing things. antialiasing, transposition and such ?

At 30-12-2009 04:15, you wrote:
Show quoted textHide quoted text
>
>
>My CPU is designated as a 10Mhz.....it might me possible to change the
>quartz crystal / clocking circuit to use 10Mhz instead of 8Mhz- a 25%
>increase....
>
>Now that may be more do-able....
>
>Regards,
>Ted
>
>On Dec 29, 2009, at 4:22 PM, Brooks Mosher wrote:
>
><http://www.emulatorarchive.com/Archives/Samplers/EmaxOverview/EmaxTech/emaxtech.html>http://www.emulatorarchive.com/Archives/Samplers/EmaxOverview/EmaxTech/emaxtech.html
>
>[Non-text portions of this message have been removed]
>
>

Re: [emax] Re: Microcontroller

2009-12-30 by Michael Wisbech

Are you starting and stopping emax seq manually ?
You should set the emax Seq to start and stop from .. midi /external .. ?
Don't remember exactly.

But i had good experiences with it doing it

http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
"
1) Copy SuperMode Map with proper track/preset assignments to another
sequence location (Manage 5)
2) Turn Auto Extend on (Setup 3)
3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
4) Choose MIDI clock (Manage 2)
5) Hit “Play” on source sequencer
"
At 30-12-2009 14:33, you wrote:
Show quoted textHide quoted text
>
>
>
>I have had midi issues when trying to play (and then record) a 1/16 
>sequence into my emax at 130 bpm aprox. Some Notes were hidden and others 
>were like jumping out of synch. I finally had to put my pro tools system 
>in "manual tempo playback", then played the sequence at 70-80 bpm and so I 
>could record it (then had to do a 80 to 130 time stretch to the file, et 
>voila).
>
>--- In <mailto:emax%40yahoogroups.com>emax@yahoogroups.com, Ted Summers 
><djtbs1@...> wrote:
> >
> > Well, your assertion is assuming the MIDI timing is a CPU issue and not one
> > of a slightly off MIDI clock, or issue with the MIDI clock circuit design.
> >
> > Maybe that specific item could be looked into- does everyone have that same
> > issue with the MIDI- or is something wrong with the MIDI circuit in Brooks
> > Emax?
> >
> > Any comments?
> >
> > Regards,
> > Ted
> >
> >
>
>

Re: Microcontroller

2009-12-30 by thenewyorkcowboy

I realized after I hit 'send' it that 'replacing' the CPU was not really feasible, we've had that thread before.

I guess I was thinking about a way to make something like an on-the-fly interpreter or decomplier, like whatever binary code is being processed it could be displayed elsewhere converted into hex.  Then you would simply go through all the buttons and parameters one by one and you would begin to see what commands do what and where the subroutines are by comparing the unique pattern to the various binary images we already have as well as the OS.  Kind of like reverse engineering by using a logic probe like we already talked about but something that would temporarily clip on or piggyback off the I/O and monitor all the pins at once.  I figured that this 8Mhz processor could simply be an interface to a machine code monitor of raw data to display it on a computer screen like 'action replay' does on the Commodore 64.

Either way, it is hair-brained or hare-brained.  I do enjoy using this forum though as a think tank over a cup of coffee...

Once we get the FAQ established and tweaked and the RS-422 project is out we'll bask in glory and talk about all the new stuff we're able to do and that will spark more interesting conversations...

--- In emax@yahoogroups.com, tu@... wrote:
Show quoted textHide quoted text
>
> The fundamental issue is we do not have the source code, let alone the documentation and development environment. We 
> have the binaries for the boot ROMs and disk OS but that is not the same as the source code. Its a long a difficult road to 
> disassemble and understand binary files and it is not made any easier by the Emax using a fairly obscure and complicated 
> main CPU. So what you suggest is unlikely to happen any time soon.
> 
> /Tristan
> 
> On Wed, Dec 30th, 2009 at 4:59 AM, thenewyorkcowboy <thenewyorkcowboy@...> wrote:
> 
> > I just saw this post on the Yamaha DX group and thought I would put
> > it here for us to comment on as well.  Don't know how it might apply
> > but ideas are welcome.  My initial thought is somehow using this to
> > translate the EMAX source code into something that we could
> > understand and modify, then we could write a new OS that would
> > implement the new features of the extra stuff we put in, or possibly
> > if the stars were aligned we could even replace the dated
> > microprocessor of the EMAX with this one and write brand new code...
> > 
> > Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
> > 
> > Re: Editor Librarians for TX81Z
> > Posted by: "Alan Probandt" alan_probandt at yahoo.com  
> > alan_probandt
> > Mon Dec 28, 2009 7:18 am (PST)
> > 
> > 
> > Hello,
> >   I have noticed the trend towards over-complication that was
> > mentioned in your message and agree.  However instead of resurrecting
> > 1980s 8-bit home computers, I suggest looking into the modern
> > microcontroller scene that is always improving in terms of
> > performance for the price.
> >   I have been doing MIDI development with the Atmel AVR
> > microcontroller a lot for the past five years or so.  I don't have a
> > lot to show for it, from a professional perspective, but what has
> > been done is in open source and available.  The AVR is almost a 1980s
> > home computer on a inexpensive chip.  There is a 20MHz CPU core
> > running 130+ op-codes, two or three input/output ports, a  serial
> > port UART or two, a cluster of 10 bit analog/digital convertors,
> > several timers, and a Flash ROM space of 4K bytes to 128K bytes. 
> > Lacking is big on-board RAM, video, and sound generators.   Programs
> > are written in free assemblers or C compilers and loaded into the
> > flash ROM.  No need for ultraviolet erasers any more. All programs
> > are stored in the ROM. No program code runs from RAM, which makes
> > AVRs different from home computers.
> >   Video can be done using attached LCD graphics modules that sell for
> > about $20.  Sound ICs have disappeared probably for good, but MP3 and
> > MIDI are straightforward to implement.  Massive data storage is done
> > on small cheap SD Flash cards at a cost of about $10 per gigabyte.
> >   AVRs have the same programming 'feel' that the old home computers
> > do, but they are much more widely available.  There isn't any concern
> > that a program written for DOS or Commodore 64 can't be shared
> > because the hardware is unobtainable.
> >   The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being
> > replaced by the $4 50MHz 32bit ARM-family of microcontrollers,
> > specifically the Cortex M3.  This device is made by many companies,
> > but it is much more difficult to program and is 'overkill' for MIDI
> > applications.
> >  
> >   Just a brief update on the alternatives to using unprogrammable
> > desktop PCs for MIDI applications.
> > 
> >
>

RE: [emax] Re: Microcontroller

2009-12-30 by el macaco

I was wondering if this timing issue happens with external sequencing as well?  I rarely used the internal sequencer, but sequenced from MPC's I never noticed too much slop or anything.  If coming from a computer sequencer then the timing issues may originate from that end, I have seen a lot of computer midi interfaces screw up timing, which gets compoounded the more data the computer tries to push out.  But it is not unreasonable for the emax to have this flaw, I don't have it do too much drum wise.

 

This may explain why the SP-12 and 1200 are so tight but lack so many of the features of the EII and Emax.

 


 


To: emax@yahoogroups.com
Show quoted textHide quoted text
From: michael@inoutflux.dk
Date: Wed, 30 Dec 2009 17:43:08 +0100
Subject: Re: [emax] Re: Microcontroller

  



Are you starting and stopping emax seq manually ?
You should set the emax Seq to start and stop from .. midi /external .. ?
Don't remember exactly.

But i had good experiences with it doing it

http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
"
1) Copy SuperMode Map with proper track/preset assignments to another
sequence location (Manage 5)
2) Turn Auto Extend on (Setup 3)
3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
4) Choose MIDI clock (Manage 2)
5) Hit �Play� on source sequencer
"
At 30-12-2009 14:33, you wrote:
>
>
>
>I have had midi issues when trying to play (and then record) a 1/16 
>sequence into my emax at 130 bpm aprox. Some Notes were hidden and others 
>were like jumping out of synch. I finally had to put my pro tools system 
>in "manual tempo playback", then played the sequence at 70-80 bpm and so I 
>could record it (then had to do a 80 to 130 time stretch to the file, et 
>voila).
>
>--- In <mailto:emax%40yahoogroups.com>emax@yahoogroups.com, Ted Summers 
><djtbs1@...> wrote:
> >
> > Well, your assertion is assuming the MIDI timing is a CPU issue and not one
> > of a slightly off MIDI clock, or issue with the MIDI clock circuit design.
> >
> > Maybe that specific item could be looked into- does everyone have that same
> > issue with the MIDI- or is something wrong with the MIDI circuit in Brooks
> > Emax?
> >
> > Any comments?
> >
> > Regards,
> > Ted
> >
> >
>
>




 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

[Non-text portions of this message have been removed]

Re: [emax] Re: Microcontroller

2009-12-30 by Brooks Mosher

i think people misunderstood me - my timing issues are with the Emax being
triggered by a Yamaha RS7000.  i have NO timing issues when the RS7000
triggers any other piece of gear, *only* with the Emax.  i have never used
the Emax's internal sequencer.

again the timing issues becomes more apparent the more notes that get sent
to it, and it really becomes an issue with drums that are being triggered by
a 16th note pattern for example.  the work around is to solo each part
separately and multi track it.



On Wed, Dec 30, 2009 at 1:59 PM, el macaco <elmacaco@...> wrote:

>
> I was wondering if this timing issue happens with external sequencing as
> well?  I rarely used the internal sequencer, but sequenced from MPC's I
> never noticed too much slop or anything.  If coming from a computer
> sequencer then the timing issues may originate from that end, I have seen a
> lot of computer midi interfaces screw up timing, which gets compoounded the
> more data the computer tries to push out.  But it is not unreasonable for
> the emax to have this flaw, I don't have it do too much drum wise.
>
>
>
> This may explain why the SP-12 and 1200 are so tight but lack so many of
> the features of the EII and Emax.
>
>
>
>
>
>
>
> To: emax@yahoogroups.com
> From: michael@...
> Date: Wed, 30 Dec 2009 17:43:08 +0100
> Subject: Re: [emax] Re: Microcontroller
>
>
>
>
>
> Are you starting and stopping emax seq manually ?
> You should set the emax Seq to start and stop from .. midi /external .. ?
> Don't remember exactly.
>
> But i had good experiences with it doing it
>
>
> http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
> "
> 1) Copy SuperMode Map with proper track/preset assignments to another
> sequence location (Manage 5)
> 2) Turn Auto Extend on (Setup 3)
> 3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
> 4) Choose MIDI clock (Manage 2)
> 5) Hit �Play� on source sequencer
> "
> At 30-12-2009 14:33, you wrote:
> >
> >
> >
> >I have had midi issues when trying to play (and then record) a 1/16
> >sequence into my emax at 130 bpm aprox. Some Notes were hidden and others
> >were like jumping out of synch. I finally had to put my pro tools system
> >in "manual tempo playback", then played the sequence at 70-80 bpm and so I
> >could record it (then had to do a 80 to 130 time stretch to the file, et
> >voila).
> >
> >--- In <mailto:emax%40yahoogroups.com <emax%2540yahoogroups.com>>
> emax@yahoogroups.com, Ted Summers
> ><djtbs1@...> wrote:
> > >
> > > Well, your assertion is assuming the MIDI timing is a CPU issue and not
> one
> > > of a slightly off MIDI clock, or issue with the MIDI clock circuit
> design.
> > >
> > > Maybe that specific item could be looked into- does everyone have that
> same
> > > issue with the MIDI- or is something wrong with the MIDI circuit in
> Brooks
> > > Emax?
> > >
> > > Any comments?
> > >
> > > Regards,
> > > Ted
> > >
> > >
> >
> >
>
>
>
>
>
> _________________________________________________________________
> Hotmail: Powerful Free email with security by Microsoft.
> http://clk.atdmt.com/GBL/go/171222986/direct/01/
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Emax and Emax II User's Group Website
>
> http://www.silveriafamily.comYahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Re: [emax] Re: Microcontroller

2009-12-30 by Patrick R

Are you sending everything on one channel? Perhaps you are running into a midi channel bandwidth limitation. Dropping notes does sound like a typical resultant.


patrick



________________________________
Show quoted textHide quoted text
From: Brooks Mosher <brooksmosher@...>
To: emax@yahoogroups.com
Sent: Wed, December 30, 2009 12:10:03 PM
Subject: Re: [emax] Re: Microcontroller

i think people misunderstood me - my timing issues are with the Emax being
triggered by a Yamaha RS7000.  i have NO timing issues when the RS7000
triggers any other piece of gear, *only* with the Emax.  i have never used
the Emax's internal sequencer.

again the timing issues becomes more apparent the more notes that get sent
to it, and it really becomes an issue with drums that are being triggered by
a 16th note pattern for example.  the work around is to solo each part
separately and multi track it.



On Wed, Dec 30, 2009 at 1:59 PM, el macaco <elmacaco@...> wrote:

>
> I was wondering if this timing issue happens with external sequencing as
> well?  I rarely used the internal sequencer, but sequenced from MPC's I
> never noticed too much slop or anything.  If coming from a computer
> sequencer then the timing issues may originate from that end, I have seen a
> lot of computer midi interfaces screw up timing, which gets compoounded the
> more data the computer tries to push out.  But it is not unreasonable for
> the emax to have this flaw, I don't have it do too much drum wise.
>
>
>
> This may explain why the SP-12 and 1200 are so tight but lack so many of
> the features of the EII and Emax.
>
>
>
>
>
>
>
> To: emax@yahoogroups.com
> From: michael@inoutflux.dk
> Date: Wed, 30 Dec 2009 17:43:08 +0100
> Subject: Re: [emax] Re: Microcontroller
>
>
>
>
>
> Are you starting and stopping emax seq manually ?
> You should set the emax Seq to start and stop from .. midi /external .. ?
> Don't remember exactly.
>
> But i had good experiences with it doing it
>
>
> http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
> "
> 1) Copy SuperMode Map with proper track/preset assignments to another
> sequence location (Manage 5)
> 2) Turn Auto Extend on (Setup 3)
> 3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
> 4) Choose MIDI clock (Manage 2)
> 5) Hit “Play” on source sequencer
> "
> At 30-12-2009 14:33, you wrote:
> >
> >
> >
> >I have had midi issues when trying to play (and then record) a 1/16
> >sequence into my emax at 130 bpm aprox. Some Notes were hidden and others
> >were like jumping out of synch. I finally had to put my pro tools system
> >in "manual tempo playback", then played the sequence at 70-80 bpm and so I
> >could record it (then had to do a 80 to 130 time stretch to the file, et
> >voila).
> >
> >--- In <mailto:emax%40yahoogroups.com <emax%2540yahoogroups.com>>
> emax@yahoogroups.com, Ted Summers
> ><djtbs1@...> wrote:
> > >
> > > Well, your assertion is assuming the MIDI timing is a CPU issue and not
> one
> > > of a slightly off MIDI clock, or issue with the MIDI clock circuit
> design.
> > >
> > > Maybe that specific item could be looked into- does everyone have that
> same
> > > issue with the MIDI- or is something wrong with the MIDI circuit in
> Brooks
> > > Emax?
> > >
> > > Any comments?
> > >
> > > Regards,
> > > Ted
> > >
> > >
> >
> >
>
>
>
>
>
> _________________________________________________________________
> Hotmail: Powerful Free email with security by Microsoft.
> http://clk.atdmt.com/GBL/go/171222986/direct/01/
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Emax and Emax II User's Group Website
>
> http://www.silveriafamily.comYahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]



------------------------------------

Emax and Emax II User's Group Website

http://www.silveriafamily.comYahoo! Groups Links




      

[Non-text portions of this message have been removed]

Re: [emax] Re: Microcontroller

2009-12-30 by Michael Wisbech

At 30-12-2009 21:10, you wrote:
You are aware that Emax has 8 note polyphony ? 8 notes at same time.

And if you sends a lot  of continious controller data it can choke, because 
of the midi stream is too condensed.
Show quoted textHide quoted text
>I finally had to put my pro tools system in "manual tempo playback", then 
>played the sequence at 70-80 bpm and so I could record it (then had to do 
>a 80 to 130 time stretch to the file, et voila).

>again the timing issues becomes more apparent the more notes that get sent
>to it, and it really becomes an issue with drums that are being triggered by
>a 16th note pattern for example.  the work around is to solo each part
>separately and multi track it.

Re: [emax] Re: Microcontroller

2009-12-30 by Brooks Mosher

specifically there would be say 4 - 6 patterns running to a separate drum
sound on the same MIDI channel and the only data that gets sent AFAIK is
note and velocity, no CC data.

so you're saying maybe i should trigger the Emax in Super Mode and put each
drum sound on a separate MIDI channel?



On Wed, Dec 30, 2009 at 2:24 PM, Patrick R <designlord@...> wrote:

>
>
> Are you sending everything on one channel? Perhaps you are running into a
> midi channel bandwidth limitation. Dropping notes does sound like a typical
> resultant.
>
> patrick
>
> ________________________________
> From: Brooks Mosher <brooksmosher@... <brooksmosher%40gmail.com>>
> To: emax@yahoogroups.com <emax%40yahoogroups.com>
> Sent: Wed, December 30, 2009 12:10:03 PM
>
> Subject: Re: [emax] Re: Microcontroller
>
> i think people misunderstood me - my timing issues are with the Emax being
> triggered by a Yamaha RS7000. i have NO timing issues when the RS7000
> triggers any other piece of gear, *only* with the Emax. i have never used
> the Emax's internal sequencer.
>
> again the timing issues becomes more apparent the more notes that get sent
> to it, and it really becomes an issue with drums that are being triggered
> by
> a 16th note pattern for example. the work around is to solo each part
> separately and multi track it.
>
> On Wed, Dec 30, 2009 at 1:59 PM, el macaco <elmacaco@...<elmacaco%40hotmail.com>>
> wrote:
>
> >
> > I was wondering if this timing issue happens with external sequencing as
> > well? I rarely used the internal sequencer, but sequenced from MPC's I
> > never noticed too much slop or anything. If coming from a computer
> > sequencer then the timing issues may originate from that end, I have seen
> a
> > lot of computer midi interfaces screw up timing, which gets compoounded
> the
> > more data the computer tries to push out. But it is not unreasonable for
> > the emax to have this flaw, I don't have it do too much drum wise.
> >
> >
> >
> > This may explain why the SP-12 and 1200 are so tight but lack so many of
> > the features of the EII and Emax.
> >
> >
> >
> >
> >
> >
> >
> > To: emax@yahoogroups.com <emax%40yahoogroups.com>
> > From: michael@... <michael%40inoutflux.dk>
> > Date: Wed, 30 Dec 2009 17:43:08 +0100
> > Subject: Re: [emax] Re: Microcontroller
> >
> >
> >
> >
> >
> > Are you starting and stopping emax seq manually ?
> > You should set the emax Seq to start and stop from .. midi /external .. ?
> > Don't remember exactly.
> >
> > But i had good experiences with it doing it
> >
> >
> >
> http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
> > "
> > 1) Copy SuperMode Map with proper track/preset assignments to another
> > sequence location (Manage 5)
> > 2) Turn Auto Extend on (Setup 3)
> > 3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
> > 4) Choose MIDI clock (Manage 2)
> > 5) Hit �Play� on source sequencer
> > "
> > At 30-12-2009 14:33, you wrote:
> > >
> > >
> > >
> > >I have had midi issues when trying to play (and then record) a 1/16
> > >sequence into my emax at 130 bpm aprox. Some Notes were hidden and
> others
> > >were like jumping out of synch. I finally had to put my pro tools system
> > >in "manual tempo playback", then played the sequence at 70-80 bpm and so
> I
> > >could record it (then had to do a 80 to 130 time stretch to the file, et
> > >voila).
> > >
> > >--- In <mailto:emax%40yahoogroups.com <emax%2540yahoogroups.com> <emax%
> 2540yahoogroups.com>>
>
> > emax@yahoogroups.com <emax%40yahoogroups.com>, Ted Summers
> > ><djtbs1@...> wrote:
> > > >
> > > > Well, your assertion is assuming the MIDI timing is a CPU issue and
> not
> > one
> > > > of a slightly off MIDI clock, or issue with the MIDI clock circuit
> > design.
> > > >
> > > > Maybe that specific item could be looked into- does everyone have
> that
> > same
> > > > issue with the MIDI- or is something wrong with the MIDI circuit in
> > Brooks
> > > > Emax?
> > > >
> > > > Any comments?
> > > >
> > > > Regards,
> > > > Ted
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> >
> > __________________________________________________________
> > Hotmail: Powerful Free email with security by Microsoft.
> > http://clk.atdmt.com/GBL/go/171222986/direct/01/
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Emax and Emax II User's Group Website
> >
> > http://www.silveriafamily.comYahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Emax and Emax II User's Group Website
>
> http://www.silveriafamily.comYahoo! Groups Links
>
> [Non-text portions of this message have been removed]
>
>  
>


[Non-text portions of this message have been removed]

Re: [emax] Re: Microcontroller

2009-12-30 by Brooks Mosher

you actually combined a quote from me and from someone else.

i wrote:
>again the timing issues becomes more apparent the more notes that get sent
>to it, and it really becomes an issue with drums that are being triggered
by
>a 16th note pattern for example. the work around is to solo each part
>separately and multi track it.

but not the paragraph above it...


but yes, i have always been aware of the 8 note max polyphony w/ the Emax.



On Wed, Dec 30, 2009 at 4:00 PM, Michael Wisbech <michael@...>wrote:

>
>
> At 30-12-2009 21:10, you wrote:
> You are aware that Emax has 8 note polyphony ? 8 notes at same time.
>
> And if you sends a lot of continious controller data it can choke, because
> of the midi stream is too condensed.
>
>
> >I finally had to put my pro tools system in "manual tempo playback", then
> >played the sequence at 70-80 bpm and so I could record it (then had to do
> >a 80 to 130 time stretch to the file, et voila).
>
> >again the timing issues becomes more apparent the more notes that get sent
> >to it, and it really becomes an issue with drums that are being triggered
> by
> >a 16th note pattern for example. the work around is to solo each part
> >separately and multi track it.
>
>  
>


[Non-text portions of this message have been removed]

Re: [emax] Re: Microcontroller

2009-12-31 by Patrick R

I'm not positive how the resources are allocated, but if they are pooled it won't matter, yet if they are processed as discrete functions it might help. It will be simpler to attempt than trying to find a hardware or software solution.




________________________________
Show quoted textHide quoted text
From: Brooks Mosher <brooksmosher@...>
To: emax@yahoogroups.com
Sent: Wed, December 30, 2009 2:41:44 PM
Subject: Re: [emax] Re: Microcontroller

specifically there would be say 4 - 6 patterns running to a separate drum
sound on the same MIDI channel and the only data that gets sent AFAIK is
note and velocity, no CC data.

so you're saying maybe i should trigger the Emax in Super Mode and put each
drum sound on a separate MIDI channel?



On Wed, Dec 30, 2009 at 2:24 PM, Patrick R <designlord@...> wrote:

>
>
> Are you sending everything on one channel? Perhaps you are running into a
> midi channel bandwidth limitation. Dropping notes does sound like a typical
> resultant.
>
> patrick
>
> ________________________________
> From: Brooks Mosher <brooksmosher@... <brooksmosher%40gmail.com>>
> To: emax@yahoogroups.com <emax%40yahoogroups.com>
> Sent: Wed, December 30, 2009 12:10:03 PM
>
> Subject: Re: [emax] Re: Microcontroller
>
> i think people misunderstood me - my timing issues are with the Emax being
> triggered by a Yamaha RS7000. i have NO timing issues when the RS7000
> triggers any other piece of gear, *only* with the Emax. i have never used
> the Emax's internal sequencer.
>
> again the timing issues becomes more apparent the more notes that get sent
> to it, and it really becomes an issue with drums that are being triggered
> by
> a 16th note pattern for example. the work around is to solo each part
> separately and multi track it.
>
> On Wed, Dec 30, 2009 at 1:59 PM, el macaco <elmacaco@...<elmacaco%40hotmail.com>>
> wrote:
>
> >
> > I was wondering if this timing issue happens with external sequencing as
> > well? I rarely used the internal sequencer, but sequenced from MPC's I
> > never noticed too much slop or anything. If coming from a computer
> > sequencer then the timing issues may originate from that end, I have seen
> a
> > lot of computer midi interfaces screw up timing, which gets compoounded
> the
> > more data the computer tries to push out. But it is not unreasonable for
> > the emax to have this flaw, I don't have it do too much drum wise.
> >
> >
> >
> > This may explain why the SP-12 and 1200 are so tight but lack so many of
> > the features of the EII and Emax.
> >
> >
> >
> >
> >
> >
> >
> > To: emax@yahoogroups.com <emax%40yahoogroups.com>
> > From: michael@inoutflux.dk <michael%40inoutflux.dk>
> > Date: Wed, 30 Dec 2009 17:43:08 +0100
> > Subject: Re: [emax] Re: Microcontroller
> >
> >
> >
> >
> >
> > Are you starting and stopping emax seq manually ?
> > You should set the emax Seq to start and stop from .. midi /external .. ?
> > Don't remember exactly.
> >
> > But i had good experiences with it doing it
> >
> >
> >
> http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
> > "
> > 1) Copy SuperMode Map with proper track/preset assignments to another
> > sequence location (Manage 5)
> > 2) Turn Auto Extend on (Setup 3)
> > 3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
> > 4) Choose MIDI clock (Manage 2)
> > 5) Hit “Play” on source sequencer
> > "
> > At 30-12-2009 14:33, you wrote:
> > >
> > >
> > >
> > >I have had midi issues when trying to play (and then record) a 1/16
> > >sequence into my emax at 130 bpm aprox. Some Notes were hidden and
> others
> > >were like jumping out of synch. I finally had to put my pro tools system
> > >in "manual tempo playback", then played the sequence at 70-80 bpm and so
> I
> > >could record it (then had to do a 80 to 130 time stretch to the file, et
> > >voila).
> > >
> > >--- In <mailto:emax%40yahoogroups.com <emax%2540yahoogroups.com> <emax%
> 2540yahoogroups.com>>
>
> > emax@yahoogroups.com <emax%40yahoogroups.com>, Ted Summers
> > ><djtbs1@...> wrote:
> > > >
> > > > Well, your assertion is assuming the MIDI timing is a CPU issue and
> not
> > one
> > > > of a slightly off MIDI clock, or issue with the MIDI clock circuit
> > design.
> > > >
> > > > Maybe that specific item could be looked into- does everyone have
> that
> > same
> > > > issue with the MIDI- or is something wrong with the MIDI circuit in
> > Brooks
> > > > Emax?
> > > >
> > > > Any comments?
> > > >
> > > > Regards,
> > > > Ted
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> >
> > __________________________________________________________
> > Hotmail: Powerful Free email with security by Microsoft.
> > http://clk.atdmt.com/GBL/go/171222986/direct/01/
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Emax and Emax II User's Group Website
> >
> > http://www.silveriafamily.comYahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Emax and Emax II User's Group Website
>
> http://www.silveriafamily.comYahoo! Groups Links
>
> [Non-text portions of this message have been removed]
>
>  
>


[Non-text portions of this message have been removed]



------------------------------------

Emax and Emax II User's Group Website

http://www.silveriafamily.comYahoo! Groups Links




      

[Non-text portions of this message have been removed]

Re: [emax] Re: Microcontroller

2009-12-31 by mr julian

Brooks Mosher wrote:
> specifically there would be say 4 - 6 patterns running to a separate drum
> sound on the same MIDI channel and the only data that gets sent AFAIK is
> note and velocity, no CC data.
> 
OK, so you have a bunch of samples in the emax, all mapped to different 
MIDI notes on the same channel.... And then you have different tracks in 
your sequencer, all set to the same channel, but each containing note 
data for the different samples?

this doesn't sound that weird.

How many other synths worth of MIDI data are going down the MIDI cable 
at the same time?? (on different channels, but the same MIDI cable) do 
you have a chain of other synths that you are also sending data to?? 
this could be more of a problem than what you've described so far.

Re: [emax] Re: Microcontroller

2009-12-31 by tu@...

Running in supermode is unlikely to fix this issue. In fact it may make it worse, as multiple note on 
messages can be sent more efficiently over a single channel than spread over several channels. 

It sounds more likely that you have polyphony issues if the timing is fine when each drum is 
soloed. If all 8 voices are in use (either in sustain or release) then the Emax probably fades out 
each stolen voice before reallocating to a new note on event. This causes a delay before the next 
note is triggered. If it didn't you might hear clicks and pops as voices were being cut off. 
Reallocating voices in this way is nice for strings etc but not so good for drums.

But it may be possible to work around this problem. How long are your note event triggers? Are 
you using very short note on/off events or longer 16th notes etc? What decay/release times are 
you using on the voice envelopes? Are you using fixed voice allocation or dynamic allocation?

/Tristan

On Thu, Dec 31st, 2009 at 9:41 AM, Brooks Mosher <brooksmosher@...> wrote:

> specifically there would be say 4 - 6 patterns running to a separate
> drum
> sound on the same MIDI channel and the only data that gets sent AFAIK
> is
> note and velocity, no CC data.
> 
> so you're saying maybe i should trigger the Emax in Super Mode and
> put each
> drum sound on a separate MIDI channel?
> 
> 
> 
> On Wed, Dec 30, 2009 at 2:24 PM, Patrick R <designlord@...>
> wrote:
> 
> >
> >
> > Are you sending everything on one channel? Perhaps you are running
> into a
> > midi channel bandwidth limitation. Dropping notes does sound like a
> typical
> > resultant.
> >
> > patrick
> >
> > ________________________________
> > From: Brooks Mosher <brooksmosher@...
> <brooksmosher%40gmail.com>>
> > To: emax@yahoogroups.com <emax%40yahoogroups.com>
> > Sent: Wed, December 30, 2009 12:10:03 PM
> >
> > Subject: Re: [emax] Re: Microcontroller
> >
> > i think people misunderstood me - my timing issues are with the
> Emax being
> > triggered by a Yamaha RS7000. i have NO timing issues when the
> RS7000
> > triggers any other piece of gear, *only* with the Emax. i have
> never used
> > the Emax's internal sequencer.
> >
> > again the timing issues becomes more apparent the more notes that
> get sent
> > to it, and it really becomes an issue with drums that are being
> triggered
> > by
> > a 16th note pattern for example. the work around is to solo each
> part
> > separately and multi track it.
> >
> > On Wed, Dec 30, 2009 at 1:59 PM, el macaco
> <elmacaco@...<elmacaco%40hotmail.com>>
> > wrote:
> >
> > >
> > > I was wondering if this timing issue happens with external
> sequencing as
> > > well? I rarely used the internal sequencer, but sequenced from
> MPC's I
> > > never noticed too much slop or anything. If coming from a
> computer
> > > sequencer then the timing issues may originate from that end, I
> have seen
> > a
> > > lot of computer midi interfaces screw up timing, which gets
> compoounded
> > the
> > > more data the computer tries to push out. But it is not
> unreasonable for
> > > the emax to have this flaw, I don't have it do too much drum
> wise.
> > >
> > >
> > >
> > > This may explain why the SP-12 and 1200 are so tight but lack so
> many of
> > > the features of the EII and Emax.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > To: emax@yahoogroups.com <emax%40yahoogroups.com>
> > > From: michael@... <michael%40inoutflux.dk>
> > > Date: Wed, 30 Dec 2009 17:43:08 +0100
> > > Subject: Re: [emax] Re: Microcontroller
> > >
> > >
> > >
> > >
> > >
> > > Are you starting and stopping emax seq manually ?
> > > You should set the emax Seq to start and stop from .. midi
> /external .. ?
> > > Don't remember exactly.
> > >
> > > But i had good experiences with it doing it
> > >
> > >
> > >
> >
> http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-
_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%
20manual/12-Sequencer.pdf
Show quoted textHide quoted text
> > > "
> > > 1) Copy SuperMode Map with proper track/preset assignments to
> another
> > > sequence location (Manage 5)
> > > 2) Turn Auto Extend on (Setup 3)
> > > 3) Turn MIDI Start/Stop on for the current preset (Preset Def.
> 7)
> > > 4) Choose MIDI clock (Manage 2)
> > > 5) Hit \ufffdPlay\ufffd on source sequencer
> > > "
> > > At 30-12-2009 14:33, you wrote:
> > > >
> > > >
> > > >
> > > >I have had midi issues when trying to play (and then record) a
> 1/16
> > > >sequence into my emax at 130 bpm aprox. Some Notes were hidden
> and
> > others
> > > >were like jumping out of synch. I finally had to put my pro
> tools system
> > > >in "manual tempo playback", then played the sequence at 70-80
> bpm and so
> > I
> > > >could record it (then had to do a 80 to 130 time stretch to the
> file, et
> > > >voila).
> > > >
> > > >--- In <mailto:emax%40yahoogroups.com <emax%2540yahoogroups.com>
> <emax%
> > 2540yahoogroups.com>>
> >
> > > emax@yahoogroups.com <emax%40yahoogroups.com>, Ted Summers
> > > ><djtbs1@...> wrote:
> > > > >
> > > > > Well, your assertion is assuming the MIDI timing is a CPU
> issue and
> > not
> > > one
> > > > > of a slightly off MIDI clock, or issue with the MIDI clock
> circuit
> > > design.
> > > > >
> > > > > Maybe that specific item could be looked into- does everyone
> have
> > that
> > > same
> > > > > issue with the MIDI- or is something wrong with the MIDI
> circuit in
> > > Brooks
> > > > > Emax?
> > > > >
> > > > > Any comments?
> > > > >
> > > > > Regards,
> > > > > Ted
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > > __________________________________________________________
> > > Hotmail: Powerful Free email with security by Microsoft.
> > > http://clk.atdmt.com/GBL/go/171222986/direct/01/
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Emax and Emax II User's Group Website
> > >
> > > http://www.silveriafamily.comYahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> > ------------------------------------
> >
> > Emax and Emax II User's Group Website
> >
> > http://www.silveriafamily.comYahoo! Groups Links
> >
> > [Non-text portions of this message have been removed]
> >
> >  
> >
> 
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
> ------------------------------------
> 
> Emax and Emax II User's Group Website
> 
> http://www.silveriafamily.comYahoo! Groups Links
> 
> 
> 
> 
>

Re: [emax] Re: Microcontroller

2009-12-31 by tu@...

What you describe is one method of reverse engineering. It can be done using a logic analyzer with 
a disassembly pod or by writing your own script/program to process the analyzer data. But 
because the NSC32000 CPU is fairly obscure it will probably be difficult to find an off the shelf 
disassembler. So that means someone has to write one and the 32000 is much more complicated 
than a Z80.

A good place to start though would be the boot ROMs as they must contain all the code for the 
power on diagnostics and floppy/SCSI loading of the OS. If the ROM routines arre reused by the 
OS then it may be possible to make modifications at that level before attempting to hack the entire 
OS.

/Tristan
Show quoted textHide quoted text
On Thu, Dec 31st, 2009 at 4:29 AM, thenewyorkcowboy <thenewyorkcowboy@...> wrote:

> I realized after I hit 'send' it that 'replacing' the CPU was not
> really feasible, we've had that thread before.
> 
> I guess I was thinking about a way to make something like an
> on-the-fly interpreter or decomplier, like whatever binary code is
> being processed it could be displayed elsewhere converted into hex. 
> Then you would simply go through all the buttons and parameters one
> by one and you would begin to see what commands do what and where the
> subroutines are by comparing the unique pattern to the various binary
> images we already have as well as the OS.  Kind of like reverse
> engineering by using a logic probe like we already talked about but
> something that would temporarily clip on or piggyback off the I/O and
> monitor all the pins at once.  I figured that this 8Mhz processor
> could simply be an interface to a machine code monitor of raw data to
> display it on a computer screen like 'action replay' does on the
> Commodore 64.
> 
> Either way, it is hair-brained or hare-brained.  I do enjoy using
> this forum though as a think tank over a cup of coffee...
> 
> Once we get the FAQ established and tweaked and the RS-422 project is
> out we'll bask in glory and talk about all the new stuff we're able
> to do and that will spark more interesting conversations...
> 
> --- In emax@yahoogroups.com, tu@... wrote:
> >
> > The fundamental issue is we do not have the source code, let alone
> the documentation and development environment. We 
> > have the binaries for the boot ROMs and disk OS but that is not the
> same as the source code. Its a long a difficult road to 
> > disassemble and understand binary files and it is not made any
> easier by the Emax using a fairly obscure and complicated 
> > main CPU. So what you suggest is unlikely to happen any time soon.
> > 
> > /Tristan
> > 
> > On Wed, Dec 30th, 2009 at 4:59 AM, thenewyorkcowboy
> <thenewyorkcowboy@...> wrote:
> > 
> > > I just saw this post on the Yamaha DX group and thought I would
> put
> > > it here for us to comment on as well.  Don't know how it might
> apply
> > > but ideas are welcome.  My initial thought is somehow using this
> to
> > > translate the EMAX source code into something that we could
> > > understand and modify, then we could write a new OS that would
> > > implement the new features of the extra stuff we put in, or
> possibly
> > > if the stars were aligned we could even replace the dated
> > > microprocessor of the EMAX with this one and write brand new
> code...
> > > 
> > > Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
> > > 
> > > Re: Editor Librarians for TX81Z
> > > Posted by: "Alan Probandt" alan_probandt at yahoo.com  
> > > alan_probandt
> > > Mon Dec 28, 2009 7:18 am (PST)
> > > 
> > > 
> > > Hello,
> > >   I have noticed the trend towards over-complication that was
> > > mentioned in your message and agree.  However instead of
> resurrecting
> > > 1980s 8-bit home computers, I suggest looking into the modern
> > > microcontroller scene that is always improving in terms of
> > > performance for the price.
> > >   I have been doing MIDI development with the Atmel AVR
> > > microcontroller a lot for the past five years or so.  I don't
> have a
> > > lot to show for it, from a professional perspective, but what
> has
> > > been done is in open source and available.  The AVR is almost a
> 1980s
> > > home computer on a inexpensive chip.  There is a 20MHz CPU core
> > > running 130+ op-codes, two or three input/output ports, a 
> serial
> > > port UART or two, a cluster of 10 bit analog/digital convertors,
> > > several timers, and a Flash ROM space of 4K bytes to 128K bytes.
> 
> > > Lacking is big on-board RAM, video, and sound generators.  
> Programs
> > > are written in free assemblers or C compilers and loaded into
> the
> > > flash ROM.  No need for ultraviolet erasers any more. All
> programs
> > > are stored in the ROM. No program code runs from RAM, which
> makes
> > > AVRs different from home computers.
> > >   Video can be done using attached LCD graphics modules that sell
> for
> > > about $20.  Sound ICs have disappeared probably for good, but MP3
> and
> > > MIDI are straightforward to implement.  Massive data storage is
> done
> > > on small cheap SD Flash cards at a cost of about $10 per
> gigabyte.
> > >   AVRs have the same programming 'feel' that the old home
> computers
> > > do, but they are much more widely available.  There isn't any
> concern
> > > that a program written for DOS or Commodore 64 can't be shared
> > > because the hardware is unobtainable.
> > >   The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being
> > > replaced by the $4 50MHz 32bit ARM-family of microcontrollers,
> > > specifically the Cortex M3.  This device is made by many
> companies,
> > > but it is much more difficult to program and is 'overkill' for
> MIDI
> > > applications.
> > >  
> > >   Just a brief update on the alternatives to using
> unprogrammable
> > > desktop PCs for MIDI applications.
> > > 
> > >
> >
> 
> 
>

Re: Microcontroller

2010-01-01 by emax_dx5

Thanks for your useful info.

But I don't work with the Emax internal sequencer. As far as I recall, I recorded the notes on a midi track in Pro Tools, then played it back sending the data to the Emax MIDI IN port for being played, and that is when I had the stuck, out of sync notes for being played so fast. 

Note that I've quantized the notes on the PT track before triggering the emax back.
I just only sent the notes on the channel 1 (it is only One note at time, not multiple ones).



--- In emax@yahoogroups.com, Michael Wisbech <michael@...> wrote:
Show quoted textHide quoted text
>
> Are you starting and stopping emax seq manually ?
> You should set the emax Seq to start and stop from .. midi /external .. ?
> Don't remember exactly.
> 
> But i had good experiences with it doing it
> 
> http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
> "
> 1) Copy SuperMode Map with proper track/preset assignments to another
> sequence location (Manage 5)
> 2) Turn Auto Extend on (Setup 3)
> 3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
> 4) Choose MIDI clock (Manage 2)
> 5) Hit "Play" on source sequencer
> "
> At 30-12-2009 14:33, you wrote:
> >
> >
> >
> >I have had midi issues when trying to play (and then record) a 1/16 
> >sequence into my emax at 130 bpm aprox. Some Notes were hidden and others 
> >were like jumping out of synch. I finally had to put my pro tools system 
> >in "manual tempo playback", then played the sequence at 70-80 bpm and so I 
> >could record it (then had to do a 80 to 130 time stretch to the file, et 
> >voila).
> >

>

Re: Microcontroller

2010-01-01 by emax_dx5

I forgot to say I send the clock signal from Pro Tools.

--- In emax@yahoogroups.com, Michael Wisbech <michael@...> wrote:
Show quoted textHide quoted text
>
> Are you starting and stopping emax seq manually ?
> You should set the emax Seq to start and stop from .. midi /external .. ?
> Don't remember exactly.
> 
> But i had good experiences with it doing it
> 
> http://f1.grp.yahoofs.com/v1/AHk7S3-q_LSq1X7QGthLp24FHMTxy-_F10zBeE96iYsN_5hEUy363hywZZjqqT_PaSkzdQKQJuAUITic6IMf1ZBv9KJy/Emax%20II%20manual/12-Sequencer.pdf
> "
> 1) Copy SuperMode Map with proper track/preset assignments to another
> sequence location (Manage 5)
> 2) Turn Auto Extend on (Setup 3)
> 3) Turn MIDI Start/Stop on for the current preset (Preset Def. 7)
> 4) Choose MIDI clock (Manage 2)
> 5) Hit "Play" on source sequencer
> "
> At 30-12-2009 14:33, you wrote:
> >
> >
> >
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.