DEQ 2496 Remote Controll (under construction by myself)

Jump to Latest
#61
Hi

First some questions

is on the "util page 2"
the "recieve system exlusive" selected?

and is "control change mode" set to "direct" ?

If i remember correctly only the "Program change" send & recieve can be disabled.

I just checked and all the versions didn't work. :bigeyes:
But for some strange reason they work again.
Not sure what that means.


I/O page seems correctly to me.

The fact you can recieve a "dump all" means it's almost working.
Some thing is blocking the midi out signals to talk to the UC.

Check "UTIL page 2" (on the UC) be sure inputs are enabled.
Check "Midi sttings" (software) and select the correct Midi out.
Check cable!
Do not use midi tru as output!!!!!

Good luck
Regards, Simon
 
#62
Selecting MIDI channel 1 on computer's MIDI interface and the DEQ should get you started.
Click to expand...

I'm not shure what you mean by this.
A midi interface has no channel!
You can send on 16 different channels over 1 midi interface.

The DEQ2496Remote sends out an sysex command to find out what diveces are connected to the midi bus.
De UCpro sends back the name, version and channel number.
So the program can automaticly adapt to the right channel.

That's why you cannot find a channel selection in the software!

Regards,
Simon
 
#63
seoman said:


I'm not shure what you mean by this.
A midi interface has no channel!
You can send on 16 different channels over 1 midi interface.
Click to expand...

seoman, my native language isn't English but I believe we are saying the same thing here 🙂
The 16 different 'device'(*) addresses are called channels in the MIDI world. I'm not sure why, but one reason could bee that musician was used to the term channels from they're mixing console. Where most instrument's have they're own channel on the mixer. The idea was that every instrument could have they're own MIDI channel. I.e drum devices are listening/sending data on channel 10. Bass devices can use channel 3 and so forth.

(*) Early synth devices wasn't multitimbral and therefore the MIDI channel selected on the synth/drum machine was in practice equal to a instrument or device number.

Hope I didn't mess this up even more for new MIDI users.

seoman said:

The DEQ2496Remote sends out an sysex command to find out what diveces are connected to the midi bus.
De UCpro sends back the name, version and channel number.
So the program can automaticly adapt to the right channel.

That's why you cannot find a channel selection in the software!

Regards,
Simon
Click to expand...

Will this automatic scene work for users with two or more DEQ devices?

kind regards
 
#64
Will this automatic scene work for users with two or more DEQ devices?
Click to expand...

No! the program is not prepared!
But if someone could check what will happen i'really would like to know!!!!

Since I don't have 2 or mare DEQs i'l will be hard to program the software.

But try multiple instaces of the software.
Search for the DEQ's with only 1 powered on.
repeat this for every instace of the remote software
That way, it might work

Regards, Simon
 
#67
Re: hi seoman

back said:
i have not use a midi before and i am not sure what i need to make this work.

is it a usb to midi cable or is it some kind of device?

thanks in advance.
Click to expand...

Hi Back

sometimes midi is a part of a soundcard.
But lots of soundcards don't have a midi connection.

So if you want to connect the ultra curve to your PC (to upgrade the firmware or use midi commands to control the deq2496) you will need a midi connection.
the easiest way is thru a usb to midi device.

ask arround to borrow a midiconvertor and try it out.

regards simon
 
#70
Wished I had found this thread long ago. So much pain could have been avoided had I have this program. Thank you so much Seoman for making this wonderful program available.

Some weirdness with PEQ (cannot use the first row) but still usable. Love the screen dump feature! Great for documentation.

For future users: When connecting midi, don't assume in/out in/out is correct as per Info tab. May be true in general but I use the M-Audio Midsport Uno USB-to-midi interface. It needed to have in/in out/out with the DEQ2496. Almost gave up on the program until I downloaded and read the Uno instructions.
 
#71
You're welcome

The program isn't running well or running at all on the latest windows systems.
The midi core of the program uses a type of variable wich isn't allowed by the XP-core any more.
Haven't found a work arround yet.

Tried the latest Delphi to solve it but i failed.

So i'm glad it's running on your PC.

Could you tell me your system setup.
service packs xp / vista etc
 
#72
Seoman, I didn't know the program has problem with the latest Windows.

I loaded it onto an old IBM T22 laptop running Windows XP, Version 5.1, Build 2600, Service Pack 2. It was what came with that laptop.

I'd better keep it around just for this purpose. I just ordered another DEQ2496 for the bedroom sound system.
 
#73
This looks to be an excellent program, very nice interface and just what I'm looking for. Only one problem, I'm struggling to get it working 🙁 As mentioned above there are problems with the latest versions of windows and yes, I have XP sp3.

Undaunted by such trivia I've found ways to manually poke and prod several functions into co-operation. seoman if you are still around you may find the following information useful, please note I've not used MIDI before so some of the following may be the result of my ignorance.

Software:
DEQ2496RemoteNew1.4
Midi-Ox 7.0.0.365
MIDI Yoke NT 1.75

Configuration:
Config.gif


By mapping the MIDI signals through the MIDI Yoke virtual devices I can monitor communications from DEQ2496Remote to see what is going on...

Monitors.gif


... and manually insert messages to try and get the correct behaviour.

SysEx.gif


Findings:

All the dynamic information from button presses etc on the Deq appear to work without any problems. The trouble appears to be in the message sent from Remote1.4, eg

Search device shows

--> Out To MIDI Yoke: 1 F00020327f1201F7

in Remote1.4

In the midi-ox monitor I see

002573E3 1 -- F0 Buffer: 2 Bytes System Exclusive
SYSX: F0 F0
002573E3 1 -- F0 Buffer: 7 Bytes System Exclusive
SYSX: F0 00 20 32 7F 12 01
002573E3 1 -- F0 Buffer: 2 Bytes System Exclusive
SYSX: F0 F0

no F7 !

When I manually enter the message F00020327f1201F7 in the SysEx View->Command Window and select Send SysEx I get the following

0059945E MOX 1 F0 Buffer: 8 Bytes System Exclusive
SYSX: F0 00 20 32 7F 12 01 F7
0059949A MOX 3 F0 Buffer: 8 Bytes System Exclusive
SYSX: F0 00 20 32 7F 12 01 F7

... still no reply. But if I Send SysEx a second time

005AC5EA MOX 1 F0 Buffer: 8 Bytes System Exclusive
SYSX: F0 00 20 32 7F 12 01 F7
005AC626 MOX 3 F0 Buffer: 8 Bytes System Exclusive
SYSX: F0 00 20 32 7F 12 01 F7
002A9745 9 3 F0 Buffer: 22 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 02 44 45 51 32 34 39 36 20 56 20 32
SYSX: 2E 32 00 F7
002A9718 1 1 F0 Buffer: 8 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 60 00
002A9718 1 1 F0 Buffer: 2 Bytes System Exclusive
SYSX: F0 F0

... Magic 🙂 This always works on the second attempt, in fact if I send F00020327f1201F7 F00020327f1201F7 , as a single message I get one reply for each send.


Bypass PEQ:

From Remote1.4 I see

--> Out To MIDI Yoke: 1 f00020320012220701080100f7
--> Out To MIDI Yoke: 1 f00020320012220701020100f7

in Midi-ox this appears as

002F2F30 1 1 F0 Buffer: 12 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 22 07 01 02 01 00
002F2F30 1 1 F0 Buffer: 2 Bytes System Exclusive
SYSX: F0 F0
002F2F30 1 1 F0 Buffer: 12 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 22 07 01 08 01 00
002F2F30 1 1 F0 Buffer: 2 Bytes System Exclusive
SYSX: F0 F0

... once again no sign of the F7 code and the PEQ does not change.

If I manually send

F0 00 20 32 00 12 22 07 01 02 01 00 f7
F0 00 20 32 00 12 22 07 01 08 01 00 f7

I get

0061DD03 MOX 1 F0 Buffer: 13 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 22 07 01 02 01 00 F7
0061DD3F MOX 3 F0 Buffer: 13 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 22 07 01 02 01 00 F7
0061DD7E MOX 1 F0 Buffer: 13 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 22 07 01 08 01 00 F7
0061DDBA MOX 3 F0 Buffer: 13 Bytes System Exclusive
SYSX: F0 00 20 32 00 12 22 07 01 08 01 00 F7

... and PEQ updates correctly

Similar behaviour with ScreenDump, GEQ selected, click Get ScreenDump:

--> Out To MIDI Yoke: 1 F0002032001276F7

shows in the Midi-Ox monitor as

003B7166 1 1 F0 Buffer: 7 Bytes System Exclusive
SYSX: F0 00 20 32 26 12 76
003B7166 1 1 F0 Buffer: 2 Bytes System Exclusive
SYSX: F0 F0

... sending the message F0002032001276F7 manually does not always work on the first attempt but sending it a second time appears to be successful - in the last test I just tried it took 3 attempts 🙄

Ok, what does all this mean ?

1) I think your program is working mostly as it should but for some reason under XP the last byte you send is going missing, I've seen similar things happen in more general serial communications. A quick and nasty fix would be to send an extra F7 at the end of each message.

2) I have no explanation why it should sometimes take 2 or 3 messages before some data is returned. A fix for this may be to wait 1/2 a second after sending and if no data has been returned then repeat the message. You could maybe repeat this wait and retry the sequence 2 or 3 times before giving up. This is trick that is often used in communications to avoid problems with line noise and other potentially nasty issues.

3) The command Application.ProcessMessages in Delphi can solve a multitude of timing problems.

Phew, it's been a long day, lol. If you wish to release your source code I have a full Delphi 7 development environment available and I'm willing to help try and fix these problems. You have put lot of effort into this program, it would be a shame for it to go to waste.

best regards.
 
#76
Thanx ecat for this responce.

The midi unit wich i use in the software will not compile with the Delphi 2009 compiler, the Delphi 2005 did raise a warning but compiled it and it has been working till (xp sp3??? ).

I got an error "[DCC Error] midi.pas(347): E2010 Incompatible types: 'TSysExBuffer' and 'PAnsiChar'"

type
TSysExBuffer = array[0..cSysExBufferSize] of char;

So i think the compatibility between PAnsichar and char has changed.

But i don't see how to fixe it.

You found out that the last sysexbyte got lost which seems pretty logical if the midi core uses a diffent kind of string/array of char then what XP understands.

So if you are willing to look at the midi core, you are more then welcome to do so!
http://www.midimountain.com/delphi_midi.html
There's enough to do on the rest of the program but with the disfunctioning midicore all other effords are waist of time.

But I will try the Extra F7 what you suggested.
And report if that will fixe it.
But that has to be done in delphi 2005. 🙁

I'm still a bit reluctant on sharing the complete project.
But you are right it has been a lot of work so far, it would be a waist if it stopped working.
So mail me (see info tab in the program)

Thanks again for all the effort you put into it!

Regards ,
Simon
 
#77
Re: WOW!

sendler said:
That's a lot of work! I just place my DEQ right in front of me while adjusting
Click to expand...

One of these EQ'ing projects usually takes me a month. Adjusting the EQ is not too much of a problem for me. I just call out "10KHz, -2dB" and my wife makes the adjustment 🙂.

The problem is in documenting the various curves, writing down lots of numbers for comparison, and often making mistakes that are not discovered until too late. So for me this is godsend.
 
#78
Ok, I've had a little poke around some Delphi sites, if the problem is down to data types then the following may help.

Char is no longer to guaranteed to be a single byte
http://www.delphibasics.co.uk/RTL.asp?Name=Char

therefore PChar is no longer guaranteed to be interchangeable with byte pointers
http://www.delphibasics.co.uk/RTL.asp?Name=PChar

There appears to be a solution. AnsiChar appears to be a replacement for the old Char type, it is guaranteed to be a single 8 bit byte
http://www.delphibasics.co.uk/RTL.asp?Name=AnsiChar

therefore PAnsiChar is guaranteed to be interchangeable with byte pointers
http://www.delphibasics.co.uk/RTL.asp?Name=PAnsiChar

So, what does all this mean ? Char/PChar were always assumed to be byte compatible, under Delphi2005 the situation appears unclear, under Delphi2009 it appears Char is no longer byte compatible, I have no idea of the situation/changes in the Windows API.

At first look, for Delphi2009 you should prepare yourself to replace ALL occurrences of Char with AnsiChar and ALL occurrences of PChar with PAnsiChar. All occurrences in all source code. Make a backup first 🙂

In the example you have presented here
type
TSysExBuffer = array[0..cSysExBufferSize] of char;

becomes
type
TSysExBuffer = array[0..cSysExBufferSize] of AnsiChar;

Sounds easy, but now we come to the tricky parts such as
SysExHeader: TMidiHdr;

TMidiHdr, appears to be a type provided as part of Delphi and is probably linked to the Windows API. It is defined in the file \source\Win32\rtl\win\MMSystem.pas , (this is the Delphi2005 file path, it may differ under Delphi2009...) . Perhaps some further investigation is required before changing all source (perhaps not, it may work 😉 )

2005 TMidiHdr Definition :

1102 type
1103 PMidiHdr = ^TMidiHdr;
1104 {$EXTERNALSYM midihdr_tag}
1105 midihdr_tag = record
1106 lpData: PChar; { pointer to locked data block }
1107 dwBufferLength: DWORD; { length of data in data block }
1108 dwBytesRecorded: DWORD; { used for input only }
1109 dwUser: DWORD; { for client's use }
1110 dwFlags: DWORD; { assorted flags (see defines) }
1111 lpNext: PMidiHdr; { reserved for driver }
1112 reserved: DWORD; { reserved for driver }
1113 dwOffset: DWORD; { Callback offset into buffer }
1114 dwReserved: array[0..7] of DWORD; { Reserved for MMSYSTEM }
1115 end;
1116 TMidiHdr = midihdr_tag;


The line that could point to a problem...
1106 lpData: PChar; { pointer to locked data block }

... if 2005 implements chars as bytes, then why is there a problem when your app is built under 2005 ? Windows API perhaps ?

Can you please post the definition of TMidiHdr from the Delphi2009 files?

With luck M$ API and Delphi and your code can be made consistent. I'll know more once I see the 2009 MMSystem.pas file.
 
#79
Hi Ecat
There are differences in the Pmidihdr

2009 mmsystem.pas :

{ MIDI data block header }
type
PMidiHdr = ^TMidiHdr;
{$EXTERNALSYM midihdr_tag}
midihdr_tag = record
lpData: PAnsiChar; { pointer to locked data block }
dwBufferLength: DWORD; { length of data in data block }
dwBytesRecorded: DWORD; { used for input only }
dwUser: DWORD; { for client's use }
dwFlags: DWORD; { assorted flags (see defines) }
lpNext: PMidiHdr; { reserved for driver }
reserved: DWORD; { reserved for driver }
dwOffset: DWORD; { Callback offset into buffer }
dwReserved: array[0..7] of DWORD; { Reserved for MMSYSTEM }
end;
TMidiHdr = midihdr_tag;
{$EXTERNALSYM MIDIHDR}
MIDIHDR = midihdr_tag;

Does this tell you enough?

Regards
Simon
 
#80
seoman said:

Does this tell you enough?
Click to expand...

Hi Simon,

Yes, I think that tells us what we wanted to hear. The line

lpData: PAnsiChar; { pointer to locked data block }

shows that the Delphi people have done exactly what I mentioned in my previous post, they've changed all the old references to Char and PChar over to the new, 8 bit guaranteed AnsiChar and PAnsiChar 🙂 Even better, it suggests the Windows API has not changed.

It looks like you need to change all Char/PChar references in your source code, the midi interface source code and any other source you use that didn't come with Delphi over to the AnsiChar and PAnsiChar data types, if in doubt please ask. This should at least compile under Delphi2009 🙂 With a little luck the resulting executable may even work 😱

Good luck, let me know how it goes.

e.
 
You must log in or register to reply here.
Top Bottom